🔨 Controlling Rule Execution Order

How can I control the order in which Slate's automation rules run? I need these three rules to run in a very specific order.
or
I need the rules to run on person records in the order they were queued up.

You can't.

But I really want to. Our Associate Vice President of Importantness said that staff assignments must be true round-robin (except on the second Tuesday of the month, when we want a manual override option).

You really can't.

Slate's rules engine uses a multi-threaded process to evaluate exclusivity groups in parallel across multiple records. In other words, the rules are running at the exact same time on both Person A and Person B, and the results are written to the database in a batch. The results for B cannot depend on the results for A.

Ok, what are our options?

Rules should be written such that the results are idempotent. a = 1 + 1 is idempotent; the result will always be 2. a = a + 1 is not idempotent, as the results change each time it's run.

There's one out, though. Slate's rules execute a second pass if the first pass produces changes, so it's OK to have Rule B depend on Rule A for the same records. It's not OK to introduce a Rule C that depends on Rule B.

Application Submission Trigger

When cloning an application, a rule using the application.UpdateSubmitted trigger cannot test for whether the "Waive Application Fee" box was checked on the clone dialog. The rule runs before the waiver payment activity is created.

Staff Assignments

The most common use case for ordered rule execution (which, as explained above, does not exist) is round-robin staff assignments. While you cannot build a true round-robin assignment system in Slate's rules engine, there are some options:

• You can use "non-deterministic" rules to randomly assign counselors. Like dice rolls, this will not be equal on a daily basis but should be roughly even over weeks or months.
• Find some property of persons that can roughly balance out your staff assignments. A common approach is to split by first letter groupings of names. So, for example, [A-L] goes to Counselor Jasmine and [M-Z] go to Counselor Steve.
• You can build a weighted distribution system that hashes a source of entropy, such as the record's email address, to generate a number 1-100. A user-scoped field can assign each counselor a range of "slots" 1-100 that determine who gets each record. This is very complex to build but allows pseudo-random, weighted distribution. It is deterministic, so the same email address is assigned to the same counselor each time, helping catch duplicates.