Automations are the fairy godmothers of the internet: you tell them to do stuff for you, and they do. 🧚‍♀️✨ It's a hands-off experience that rids you of tedious and error-prone manual work by manipulating data on your behalf in accordance with your commands.

In this article we extoll the benefits of automating FULL FABRIC – please read it if you haven't yet –, so here we're gonna show you how to build an automated workflow.

➜ What's an automated workflow and how does it differ from other automations?

➜ Where in FULL FABRIC can I create automated workflows?

➜ How can I automate a workflow and what tasks can be automated?

・Define the trigger

・Add another condition

・Define the task to be carried out

・Establish an exit condition

Automations are always composed of a predetermined trigger (the catalyst for what will happen) and one or more actions (the tasks you want to outsource). That said, there are two different kinds of automations in FULL FABRIC: automated workflows and system automations. Automated workflows you can build and edit directly, whereas system automations come with the system, are an intrinsic part of how it functions and can't be edited at all (for instance, an applicant::started application automatically transitioning to applicant::submitted application after submitting an application form). Only the former kind is your concern.

➜ Events

➜ Forms

➜ Applications

➜ Offers

➜ Classes

This last one deserves a note because there are currently two areas where you can create class-related workflows.

One, predictably, is inside a class:

But the second is in General settings > Institution > Lifecycle workflow, a special area where you can arrange classes into groups (formally designated as "lifecycle workflow groups") and create automations concerning every member. For instance, to group full-time and part-time classes of the same programme, since their inner-workings tend to be mostly the same. Both areas work alike.

Replacing a manual operation with an automated workflow is relatively simple:

     1) Enter the tab Automation and click Add workflow
     2) Define a trigger to set the workflow in motion
     3) Add conditions (supplementary requirements that must be met in order to bring the task to fruition)
     4) Define the actual task that you want to happen
     5) Establish an exit condition – a finish line that, once crossed to victory, terminates the workflow early

This is the general picture, but for the sake of clarity, we'll proceed to isolate each step in order to take a closer look now:

➜ Event automation workflows are typically based on people's registration responses: response is Yes, response is No or response is Maybe. However, if you don't want an automation to be contingent on the submitted responses because it fits all of the answers at the same time, then use the fourth option: namely, response is Any.

➜ When it comes to forms, automation workflows are solely based on submission: form is submitted.

➜ As for applications, there are two triggers: application is started and application is submitted.

➜ Classes are all about the life cycle of a profile, so automations are triggered by state transitions (e.g., profile state transitions from Prospect::Hot to Prospect::Engaged). The from and to dropdown menus list every state in the admissions lifecycle of your school.

Nevertheless, you don't necessarily have to specify the states if that goes contrary to what you'd like to achieve, because the from and to dropdown menus both include an additional option called any state (which is actually default). For instance, suppose there's an interaction that you want to happen whenever an applicant reaches the Prospect::Qualified stage, even if, for whatever reason, the transition skips phases (like a profile jumping straight from Prospect::Cold to Prospect::Qualified without being updated into the intermediate states along the way); in that case, the workflow should be:

The opposite can also happen, of course:

➜ Offers have three triggers: offer is made, offer is accepted and offer is declined.

The purpose of this function, which is optional, is to impose additional criteria that must be fulfilled to kick off the automation. For Events and Forms, the criteria is based on the responses to the fields in the schema.

Suppose, for instance, that you'd created a checkbox titled: WHEN ARE YOU PLANNING TO START YOUR MBA?, and, for this workflow, you'd like to specifically target the people who checked 2020 as their year of choice:

You'd then have to set that answer as the condition's VALUE, writing it in exactly the same manner as you did in the schema:

For applications, the criteria is the Primary choice programme selected by candidates. Consequently, all you have to do is tap inside the CONTEXTS box to cycle through your school's programmes and campuses and multi-select attributes:

As for classes, The capacity of the product is the criteria, as defined in the class Details tab. Pick Below the maximum capacity or Above or equal to the maximum capacity, as appropriate:

The logical operator is always AND. There's no restriction on the amount of conditions you can have. The exception is Offers, which doesn't support additional conditions.

Altogether, up to 13 actions can be automated, either in the same workflow (if the audience is the same), or in separate workflows (if you want to do different things to different people):

Although many of the actions are self-explanatory, some comments are in order:

➜ Send email and Send email to profile are the same automation under different names. The second name appears on modules that also let you Send email to staff to avoid confusion between the two. Unique to Offers and classes is the option to just generate a draft instead of dispatching the email.

➜ You have to define whether you're sending marketing correspondence or not when employing the Send email and Send email to profile actions by selecting Yes, only subscribed profiles will receive this email or No, all profiles will receive this email (default), under IS THIS A MARKETING EMAIL?. Marketing emails are only sent to subscribed users and contain an unsubscribe link in the footer, as well as the recipients' latest marketing policy agreement.

➜ Send email to staff and Send notification have distinct purposes: the former is an actual email whereby you pick an EMAIL TEMPLATE and write a SUBJECT; the other is just a generic warning letting staff know that a form was freshly submitted.

➜ Wait works in conjunction with the Send email ACTION to schedule a date to send the email, instead of sending it immediately whenever a registration is submitted that matches the workflow requisites. That way, you can schedule a series of emails to be sent in a particular order and at different specified times, in order to sustain engagement over time and educate users about your programmes, your school or even a career goal. All you have to do is determine a relative date, click Add step to define which email you want to send, and repeat for follow-up emails, like so:

Every email in the sequence must be preceded in the workflow by a Wait ACTION indicating the respective send date to nicely spread out the communications.

➜  Add profile to class and Add profile to classes by names or ids accomplish the same, but very differently. The former works by invoking the target intake by name, as (multi-)selected from a dropdown menu:  

In contrast, the latter asks you to identify the input field in the schema where you gathered submitters' intake of interest. Then, depending on the programme and class defined by the submitters, one of the following things will proceed to happen:

Exit conditions derive their name from the outcome they result in, which is a profile exiting a workflow upon a certain objective being attained. In other words, an exit condition defines when profiles exit the workflow: once the profile has fulfilled the exit condition, none of the subsequent actions in the workflow are triggered for that profile. Therefore, exit conditions are meant for workflows containing multiple steps with waiting in between.

What happens is that, upon establishing an exit condition – say, user starts any application or user submits any application –, the workflow will constantly evaluate its profiles against the condition until they effectively start or submit an application. When that moment comes, the profiles in question are removed from the workflow, even if outstanding tasks remain.

But let's examine an example: in the workflow below, belonging to a form, the plan is to firstly tag the profile and send it an email, wait three days, send another email, wait four days, and then finally send the final email. Now let's imagine someone enters the workflow, is in the three day period, but in the meanwhile starts an application – the rest of the workflow is cancelled, meaning that the emails "GMAT tips here!" and "Interview next week" won't be sent anymore.

This type of dynamic serves goal-oriented workflows, such as lead nurturing marketing campaigns, which work up to a specific feat. Since everything boils down to realizing said feat, remaining tasks are made redundant once it's in the bag, accounting for why they must be ceased.

If you don't want to employ an exit condition, just keep the default all actions have been completed.

You have reached the end of this article. Thanks for reading! 🤓 If you have any questions or comments on the topic at hand, or if you enjoy reads like this and have article requests, let us know. Also, please leave a rating below. Your feedback is highly appreciated! 💖

PUBLISHED: February 18, 2020
LAST UPDATED: January 3, 2022 at 2:03 p.m.