System options may or may not enforce data type validation.  Again, it's important to remain consistent with the option values type. For example, if the value is numeric then maintain a numeric value unless stated otherwise in the documentation.  When presented with percentages values, it's good practice to maintain a valid percentage value ( 0 - 100 ).
    
Note: Not all options behave this way, some may be configurable with numeric and string values. For example, an option to configure the shop plugin history count for viewed items is generally numeric ( 1 - 10 ) but it also has the option of "browser" which allows for the list to be as large as the customers web browser supports

All plugins have a configuration option to alter and scale their behavior.  Plugin configuration options can be access through a uniform Url; http://[your site]/[plugin name]/configuration.  Plugins and the system itself have options which are not configurable through their corresponding interface.  These are called hidden options and are meant for advanced users who understand their system in depth.  The system options interface a great utility to further alter the behaviors of your website and/or plugins.

When changing options through the system options interface, always write down the configuration option you are about to change and it's value.  This allows you to restore the configuration if needed.

In order to contact a member of your website, you must have completed the email setup process either using your personal email account or a business email account purchased through fliddo.

System messages is not an open relay meaning a user/member must exist on your website in order to contact them. System messages does not support HTML and is not an email interface meaning messages are sent via email in text format.

Many email notifications are per-defined through the use of plugins, however, there are plenty of optional ones left for you to implement. For example, the Shop plugin will setup email notifications on orders received.  This email notification is setup to be sent to you and your customer, each having the option to be a specific email message.  
        
With per-defined notifications, no further configuration is required unless you want to remove it from the notifications table.  This allows you to focus on what matters which is the content and your message by simply editing the email templates attached to notifications.
        
Note: Email messages take advantage of the Maple Template Engine.  Maple is a template language to inject live data into your web page or email content.  View the Maple Engine documentation for further information.

Email notifications can be setup so you and/or your customer receives an email after an occurrence ( event ) occurred.  Simply select an event, decide who received it and finally attach an email template.  That's it, you're done.  
        
An email notification can have up to two receivers ( you, your member/customer, or both ).  Only one email can be attached to a single receiver meaning you wouldn't be able to share an email between you and your customer but you can setup separate templates for each.

To setup a callback will require positive communication between your existing platform and fliddo meaning an existing platform must exist and sent an expected message back to us before you can complete callback support for that URL.   
            
This requires an HTTP check against the URL specified with an expected result.  The results expected is usually a JSON response with the variable Status set to OK.  Visit the callback help documentation for more information to how to fully setup your platform for callback support.
        
Setting up the callback notification is simple, select the occurrence/event and enter a callback URL to receive information on that event. During setup, you will be asked to test the URL with the endpoint provided.

Sometimes callbacks can fail, this maybe due to connections speeds, system maintenance or even software crashes.  Regardless of the reason, fliddo callback notifications operate on a retry basic to maximize sent messages.
        
Callback retries are aggregated for up to 5 times which can also be configured through system options.  The following is a breakdown of how and when retries are enforced.  In case of failure a callback is staggered as follows.

            

1. The first retry is just after the mealtime event occurs, usually about 1-3 seconds after the initial callback fails.
2. The second attempt is made minutes later, unless a positive message is received.
3. The third retry is made a couple hours later.
4. This fourth retry occurs approximately 9 hours later
5. This is the final retry which can occur between 1 to 3 days, if this retry fails, the notification will be marked as failed to deliver.

 

There are options in the system configuration to add additional retry options, read the documentation for further information.