When you receive a newly created Agillic instance, there are a couple of things for you to configure to make it fully and securely functional. If you're new to Agillic and working with an already existing instance, these settings have probably already been reviewed and set up to match your business requirements.
Below, we cover the aspects we believe are most important to configure with a new Agillic instance.
In Agillic, we have a security measure that pauses the system if we detect a misconfigured flow. If this happens, the Agillic instance will be paused and no communication will leave the instance until an Agillic user from your corporation has corrected the issue and resumed the instance.
To make sure the right people receive these alerts, it's crucial that you configure at least 1 email to be a receiver of them. We recommend that you have at least 3 people receiving the alerts to ensure that the system pause can be resolved quickly.
Read our article on how to handle a system pause here: Handling a System Pause.
In order to set up alert receivers, go to system settings and on the left, there's a section called 'alerts'. Here, simply type in the list of email addresses that will receive such alerts, separated by a comma.
In order to follow best practices for sending out emails from Agillic and ensuring correct security levels and highest possible deliverability, we strongly recommend setting up a verified domain in Agillic. This article explains exactly how you can set up a verified domain following Agillic's best practice: How to Add a Verified Domain to Agillic.
Two verified subdomains that are ready to use as the from domain in your emails.
When you receive a new Agillic instance, you should consider whether you will be sending emails from several brands or just a single brand. If you have multiple brands, you should consider enabling Agillic's brands feature. This will make your life easier as you can make sure that each brand is interconnected with a particular domain. In this way, there's no way you can send an email from the wrong brand by mistake. Brands also allow you to make sure that recipients only unsubscribe from the specific domain and not from all emails.
Here are a couple of articles to get you started working with brands and domain-based unsubscribe: Understanding Brands and Understanding Domains, Brands and Domain Based Unsubscribe.
In email settings under system settings, you can configure when your recipients should be marked as inactive. An inactive recipient is one who has not opened a number of emails over a period that is set by you. Read more about this feature here: Understanding Inactive emails.
This feature helps you keep your deliverability as high as possible while also avoiding skewed reporting of email campaigns. You can choose to simply avoid sending to recipients by checking the "do not send to inactive emails" box. By doing this, the system will by default filter out inactive recipients so you don't need to remember to do this in your target groups.
Recipients who received at least 5 emails over the past 90 days but did not open a single email in this same period is marked with INACTIVE_EMAIL = true.
Global Send Permission
As another security precaution, you can define a set of rules that must apply before any email is sent to your recipients. The rules are called conditions. You can also set some general conditions, some of which must be met for the recipient to receive emails from you.
A good example of a target group can be seen here in the example called "Valid Recipients":
A target group with a set of conditions defining a valid recipient on your instance
After you've set the conditions which define global send permission rules for your business, you can apply this target group to the global email send permission section under Email in System settings:
The target group "Valid Recipients" has been set as the global send permission on your instance
User Groups and permissions
When you set up a new Agillic instance, you should consider who will have access to the instance and what permissions these users will have. Here, you can set rules for who can see sensitive data on your recipients, such as EMAIL, FIRSTNAME, LASTNAME, or ADDRESS. You can also restrict a user group to a defined set of modules and elements in Agillic.
Unique person data fields
When setting up a new instance, one of the most important things to consider is which person data fields in your data structure should be marked as unique. One of the most commonly asked questions we get is whether EMAIL should be unique or not. This entirely depends on your data ecosystem. For example, do you want to allow recipients to share email addresses? If so, EMAIL should not be unique.
Examples of fields that are often but not necessarily unique:
- ID fields
Every Agillic instance has a recipient key. This is a unique field that's the primary identifier of your recipients. You will use it for importing data to your recipients, testing content, and for looking up recipients on your instance. Some examples of fields used for recipient keys could be:
- Customer number
- Contact ID
- Subscription ID
- Email address
You can choose whatever unique field fits your data structure as a recipient key. However, we have some best practices to stick to on this. For example, we recommend that you choose a field that is not subject to change.
Read more about our best practices for selecting your recipient key here: Best Practice for Selecting a Recipient ID.
Getting Data into Agillic
Before you start using Agillic for send-outs, you need to connect your Agillic instance to your data infrastructure. There are several ways to go about this and you have several opportunities in terms of what data you should have in Agillic and how it is created and updated.
First of all, it is important to ensure that you have the data fields in Agillic that you need. Your instance is born with a limited set of standard fields but you can create and delete as many fields as you like. You might also need to create one-to-many tables and global data tables for e.g. orders and products respectively. If you find out that you need a field, you can always create this later on. You can read more about data in Agillic here: Understanding Data Models.
Second of all, consider how often you need to update your data. If you are planning to import data once or twice a day, you might want to use the file import functionality where you can both update person data and global data tables.
Read more about data import in this article: Understanding Data Import/Export.
If you need your data to be near realtime, we recommend you use our API catalogue to keep your data updated. Find documentation on our API on our developers portal.
Best Practice: The staging and production databases are separate from eachother, so remember only to import your actual real data to your production environment. Remember also to have some test data on your staging environment that you can use for testing!
Lastly, we recommend that you consider the password requirements and security settings for user logins to your Agillic account:
How to get Support
During your work with the platform, you might experience that you need assistance. In this case, you can contact Agillic Support either by phone or through the ticket system.
Read more about how to get help from Agillic Support here: How to get Support.