Best Practice for Permissions

A permission controls if a recipient has given consent to receive communications from you. Permissions can also control what types of communication your recipients want to receive. For example, a recipient might want to receive weekly newsletter emails, but not sales emails.

In this article, you'll find information about:

• Agillic's Recommended Best Practice for Permissions
  • Defining the Permissions
  • Number of Permissions
  • A Single Permission Field
  • Permission per Outbound Communication Feature
  • Permission per Channel and Communication Type
  • Permission Timestamps
  • Permissions in a One-to-Many Table
  • Temporarily Block a Recipient
  • Blocking Personalisation of Outbound Communication
  • Making a Sign-up Considering Permissions
  • Controlling How Often to Contact a Recipient
  • Emulating Transactional Emails in Agillic

Agillic's Recommended Best Practice for Permissions

Defining the Permissions

The Person Data field 'UNSUBSCRIBED' is a premade and fixed Person Data field which exists on all Agillic Solutions. However, you're free to create one or more Person Data fields to contain your permission(s).

When creating a Person Data to contain permissions, we recommend creating the Person Data as the Boolean Data Type. This means that a recipient can only have true or false in the Permission data field. 

Number of Permissions

The number of permissions you need depends on your use case. For example, if you have lots of different sorts of communications that you send out to recipients, you might want separate permissions for each type of communication.

A Single Permission Field

One option is to have a single Person Data field which controls all permissions across channels and types of communication. This is the easiest but least flexible way of storing permissions. It means that if a recipient unsubscribes from any communication, they should no longer receive any outbound communications from you.

To work with a single permission, you can use the Fixed Person Data 'UNSUBSCRIBED' or create a Person Data field such as PERMISSION.

Permission per Outbound Communication Feature

If you send out communications on a number of channels, you could handle your permissions by channel. This would mean having different permissions for email, SMS, and push notifications.

An example of Person Data controlling permissions per feature could be:

• EMAIL_PERMISSION
• SMS_PERMISSION
• APP_PUSH_PERMISSION

With this setup, a recipient can unsubscribe from one communication feature and stay subscribed to another.

Permission per Channel and Communication Type

If you use Agillic to send a series of different types of outbound communication, you can create a set of permissions for the communication types like:

• SALES_PERMISSION
• SERVICE_PERMISSION
• MARKETING_PERMISSION

You can combine these with the channel permissions from the previous example. You will then need both Conditions to make the correct segment. Learn about how to create Conditions here.

For example, to create a Target Group for recipients who wish to get emails regarding marketing, the Conditions could then be:

• ALL
  • EMAIL_PERMISSION equals True
  • MARKETING_PERMISSION equals True

You can also look into the possibility of domain-based unsubscribe or brands if they would fit into your use case.

Permission Timestamps

When a recipient gives any permission, we recommend saving the timestamp as well. If you want to save the timestamp in Agillic, you can then set a side-effect on the permission data.

Read more about working with side-effects here.

In case of multiple permissions, you must add a timestamp per permission as these permissions can change independently. If your recipients can give their permissions via different sources, you should also create a Person Data field to note the source of the permission change. This data needs to come from the individual sources during the permission change.

Permissions in a One-to-Many Table

While technically possible, we do not recommend storing permissions in a One-to-Many Table.

This is due to the following limitations:

• Signup applications on an Agillic Webpage require more complex code to define which One-to-Many row(s) to create or update for each checkbox.
• Signup on external sites would require at least two different API calls to create the recipient. One API would retrieve all the Person Data and a second call with the permissions to add in the One-to-Many table.
• The standard questionnaire application can't create a My Profile page where the One-to-Many permissions can change. This would require a custom application instead.
• Unsubscribing can't be set up with the standard features in Agillic. You would need custom code to unsubscribe a specific permission.

Temporarily Block a Recipient

In some cases, you may want to offer a recipient the option of unsubscribing for a limited time. This rule can then apply to some or all communication features in the instance.

You can set this up by creating a date Person Data field like 'BLOCKED_UNTIL'. This date Person Data field should be set to contain the last day the recipient wishes to remain blocked. You can then include the Person Data in a Target Group like so:

• Person Data - BLOCKED_UNTIL - older than -  0 - days into the past - Condition not met

The above Condition is set to be a 'NOT met' Condition to correctly include any recipient where BLOCKED_UNTIL is blank.

Blocking Personalisation of Outbound Communication

It's possible to design a permission like PERSONALISATION. If set to 'False', the permission means the recipient will only receive generic content.

You will have to control the content itself in a completely separate communication, such as having a generic version of a newsletter as well as a personalised one. Alternatively, you can also set up this logic as a final proposition in a Promotion. This set up will demand a high level of complexity when setting up your campaigns in Agillic.

Making a Sign-up Considering Permissions

Once you've created all permission fields, you'll need to make sure new recipients can have these permissions checked during sign-up. In most cases, you'll do this with one or multiple checkboxes that recipients can enable or disable during sign-up to identify the correct set of permissions.

If you use multiple permissions, you can place a single checkbox on the sign-up form that enables all the permissions. Make sure the sign-up form doesn't have any auto-checked permissions as the recipient has to manually check the permission to verify it.

Controlling How Often to Contact a Recipient

If you're creating a series of different permissions, you'd often organise your permissions in one or more Target Groups. When you send out, your Flows can then be configured to send to certain Target Groups. Because of this setup, you may fear a recipient could get spammed or receive too many communications from the different Flows. At the moment, Agillic doesn't have a standard feature to limit the number of communications recipients should receive within a certain period. 

While Flow Conditions can filter recipients within Target Groups, this can quickly mean working with a huge number of Conditions. Instead, we recommend clarifying your permissions to the recipient. If the recipient signs up for a weekly update, a monthly newsletter, and a birthday email, the recipient could, in theory, receive 3 different outbound communications from you on the same day. But, if each outbound communication is clearly marked as a different type of outbound communication, most recipients will understand the overlap is a coincidence and not something they can expect to happen every day. If the recipient still feels that they're receiving too many communications, they can choose to unsubscribe from a specific permission, such as the weekly update, without completely unsubscribing from ever being contacted.

Emulating Transactional Emails in Agillic

In specific cases, you may want to send a type of transactional email, such as to confirm a new order or subscription. While Agillic is a Marketing Automation Platform, it's possible to use a triggered Flow to emulate some attributes of transactional emails, although with some limitations. 

In the most common transactional email cases, you can trigger a Flow with an Event using our REST API. This could be when a recipient completes a purchase from your external ordering system. If the recipient is new to your instance's database and if the email is valid, the recipient will receive the transactional email.

You should consider edge cases and limitations when setting up a transactional email if both:

• The recipient already exists in your Agillic instance.
• Has either Person Data COMPLAINT= True, or UNSUBSCRIBED = True.

In the case that recipient has been unsubscribed but triggered a transactional mail, you should set up the Event logic to resubscribe the recipient, setting UNSUBSCRIBED to False or Blank. You may also want to make sure that all other permissions are set to False or Blank. This is because the recipient may have Unsubscribed with the UNSUBSCRIBE Event to opt-out from a specific communication type. You can read more about it in the Permission per Channel and Communication Type section of this article.

When the recipient resubscribes to receive transactional emails, you'll want to ensure that they're not resubscribed to any other types of outbound communication and will only receive the transactional emails. Please note that a recipient should never be resubscribed without triggering such action themselves.

In the Event that a recipient has complained, you can't send the transactional mail as the COMPLAINT field cannot be changed. The field can't be modified by API calls or Step Side Effects and is a system-wide restriction.