Skip to main content
An automation is a rule that watches a Master List and acts on digital cards without anyone clicking anything. When a student’s status changes to Enrolled, issue their card. When an expiry date passes, revoke it. You find them on a Master List’s Automations tab.
Automations act on digital cards, so you need at least one card template before you can create a rule. The tab will tell you as much: “Automations issue or revoke digital cards, so they need at least one card template.”

​
What a rule is made of

Every rule is: when this happens → do this to their card.

​
Triggers

Field triggers are checked as changes happen — an edit, a CSV import or a directory sync all count. Date triggers are checked once a day, so a rule watching an expiry date fires on the day it passes, not the second it does.
You can trigger on the built-in Active / Inactive status as well as on your own schema fields. These are genuinely separate things: the built-in status controls whether a person is active in CaptrID, while a field you created called something like “Status” is just data. If you have both, be clear which one your rule is watching.

​
Conditions

Add as many conditions as you need and choose whether all of them must be true or any of them. Text, number, date, dropdown and yes/no fields are all supported, with the operators you would expect — equals, contains, is past, within N days.

​
Actions

Every action operates on the person’s digital card:
Suspend is usually the right choice over revoke. A student on leave, a contractor between assignments, a staff member mid-investigation — all of those come back. Suspend is reversible; revoke is not, and a revoked card has to be reissued from scratch.

​
Creating a rule

  1. Open a Master List and go to the Automations tab
  2. Create a rule — give it a name that says what it does, because that name is what you will see in the run history
  3. Choose the trigger and add conditions
  4. Choose the action and the card template it applies to
  5. Save
The rule is live immediately.

​
Watching them run

Each rule shows its own history on the tab:
  • Last run and how many times it has run in total
  • Last run failed — N time(s) if it is erroring
A rule that keeps failing is worth opening rather than ignoring. The usual causes are a card template that was archived out from under the rule, or a field that was renamed or removed since the rule was written.

​
Worth knowing before you build one

Rules fire on the change, not on the state. A rule watching for status becoming Enrolled fires when someone becomes enrolled. It will not retrospectively issue cards to people who were already enrolled when you created the rule — issue those in bulk once, then let the rule handle new arrivals. Test on a small list first. A rule on a list of two thousand people will do two thousand things. If you are automating issue-and-email, that is two thousand emails. Order matters when rules overlap. Two rules watching the same field can both fire. Prefer one rule with several conditions over several rules that might disagree.

Digital Cards

Wallet passes — what automations issue and revoke

Managing Master Lists

Schema fields, and the built-in active status

Directory Sync

Keeping the fields your rules watch up to date

Audit Logs

A record of what automations did