📌 Note: The screenshots and settings shown in this article may not match what you see in your own platform, as Rosterfy is highly customisable. If you need guidance specific to your setup, please contact our support team.
Automations save you time by handling repetitive work automatically. Instead of manual data entry, they use a logical sequence that runs based on specific events. To ensure the right result happens at the right time, every automation is built using a three-part structure:
Task: The specific event that triggers the Automation to run.
Rule: The rule that must be met for the system to proceed with the Automation.
Action: The task the system performs after the Automation has run.
For example, when a volunteer submits an application for a Shift (Task), the system checks for the specific Shift (Rule) before sending a confirmation email (Action).
💡Tip: The following section outlines details on Automation rules. See the following articles to learn more about Tasks and Actions:
IN THIS ARTICLE:
Rule Components
Rules are optional filters that determine exactly which records trigger an automation. They use specific data fields known as entities, to check if a condition is met.
Rules comprise the following components:
1. Rosterfy objects and their respective fields, including:
User: Core profile information and personal details, e.g. First Name, Age, Email
Event: General information about the Event, e.g. Event Name, Event Address, Event Type
Event Shift User: Data regarding a person's participation in a specific Shift, e.g. Check-in Date/Time, Event Shift Status
Role Offer: Details relating to specific role offers, e.g. Functional Area, Approval Status, Job Title
2. Condition operators, including:
Is Equal To: The Value field must contain exactly the value you specify.
Is Not Equal To: The Value field can contain anything except the value you specify.
Is Not Empty: The Value field must contain data. Useful for catching incomplete records.
Is One Of: The Value field must match any value from your list. Useful for multiple acceptable values and you don't want to create a separate rule for each.
Is Not One Of: Excludes the Value field and must not match any of the values in your list. The Automation will run for everyone outside that group.
3. Value fields which may comprise pre-populated dropdowns or text inputs.
💡Tip: Rules are built using conditions and values. The Values field is dynamic and determines whether you select from a pre-populated dropdown or type into a text field depending on the data you are filtering.
Automation Tasks That Require Rules
While Rules are optional, those Automation Tasks depend on them to function correctly.
Task | Why rules are required |
Any task that runs on every User or every Shift in your account.
(i.e. User-Register, Event Shift - Apply, Event User - Status Changed) | Without Rules, the Automation will apply to all Users, Events and Shifts.
Rules limit the scope of the Automation to specific Users, Events and Shifts. |
Form - Process | Without Rules, the Automation will run for every form submitted on the account. Rules narrowing to a specific form (Form ID is equal to X) are the only way to make Automations on this task useful.
|
Status changes
(i.e. Event User - Status Changed, Event Shift User - Status Changed, Role Offer User - Status Changed)
| Without Rules, the Automation will run on every status transition. Rules narrowing to a certain status transition.
i.e. Event Shift status is equal to Confirmed, will limit the the scope of the Automation to that particular status transition.
|
Date Reminder tasks
(i.e. Event - Date Reminder, User - Date Reminder, Event User - Date Reminder) | The Automation scheduler runs every night for every record where the date attribute matches the configured date. To send the reminder to one specific Event or for one specific date attribute, you need rules on the entity ID or Attribute name. |
Creating an Automation - Schedule Trigger
Before: This is a scheduled action.
After: This is a delayed action. | When an Automation runs, the system checks the Automation-level rules. If they pass, the Action is scheduled as specified in the Schedule Trigger. When the Action due to run, the system re-checks both the Automation-level and Action-level rules at that moment. If they still pass, the Action runs. If not, it won't run. |
How Automation Rules Work With Multiple Actions
Each Automation has two levels of rules and they are evaluated twice:
Automation-level: Set on the Automation itself.
Action-level: Set on individual Actions within the Automation.
💡Tip: The Automation must be saved first before you can add Action-level rules.
⚠️Warning: Rosterfy re-checks both the Automation-level and Action-level rules before running every single step in a sequence. If an early action updates a user's data so they no longer meet your main criteria, all remaining actions will be skipped. Always place data-changing updates as the final action in your automation.
Automation Rule Evaluation
For an Action to run, both the Automation-level and Action-level rules are evaluated. Both must be satisfied for the step to proceed. Adding an Action-level rule ensures the step remains valid even after data changes. See the following example:
Example: The Checkpoint Trap
You create an Automation with an Automation-level Rule: User Checkpoint is equal to Checkpoint 1, and the following Actions:
Action 1: Send email. No rules set up.
✅ Action runs: User is still at Checkpoint 1 as per the Automation-level Rule.Action 2: User Checkpoint - Update. No rules set up
✅ Action runs: When the Action is evaluated, User is still at Checkpoint 1 as per the Automation-level Rule. Afterward, User is moved to Checkpoint 2.
Action 3: Assign certificate.
❌ Action skipped: TheAutomation-level rule is no longer true because the User is no lomger at Checkpoint 1.
How to fix this: To ensure Action 3 runs, apply an Action-level rule directly to it: User Checkpoint is equal to Checkpoint 2. Adding an Action-level rule ensures the step remains valid even after data changes.
Processing Speed and Order
Beyond the logic rules, the underlying system speed can occasionally impact how actions fire. In rare cases, multiple actions within the same automation may begin processing in parallel, meaning a later action might start before a previous action has fully finished saving its data to the database.
Best Practice: Save rule-breaking actions for last to prevent inconsistent behavior caused by these rapid timing overlaps, any action that completely changes or invalidates your main automation rules should always be the final action in your sequence. Avoid early actions that disrupt the rules before subsequent steps have a chance to evaluate.