Heads-up rules
A heads-up rule marks parts of your Aprimo configuration that need extra care, and says why — so the reason travels with the change instead of living in someone's head.
Some configuration items matter more than they look. A field might be filled in by an integration, or feed a website, or be the one thing a report counts on. Anyone reading a change set sees the field and what changed about it. What they can't see is what happens next.
A heads-up rule is where you write that down. It names some of your configuration items, adds a note explaining why they matter, and lists the people who should hear about it. When a change set touches any of those items, the note is shown to whoever is reviewing, and the people you named are emailed.
The rule covers a set, not one item
Writing the same note on twenty-five fields is the kind of chore nobody keeps up to date, so a rule covers a group and one note serves all of it. A rule picks up items in three ways, and you can combine them.
- By name. Fields whose name starts with PIM_, say. This is the useful one for a naming convention: a field added next month that follows the same convention is covered the moment it appears, without anyone remembering to add it.
- By picking items. Choose items in Configuration and add them to a rule. Good for the ones you can only recognise by looking at them.
- By what uses them. Turn on Also cover anything that uses these and the rule reaches items that read the ones you named. If a rule elsewhere in your configuration reads a protected field, a change to that rule counts too.
The rule's screen shows how many items it currently covers, so a name match is a number you can check rather than a guess.
What a rule asks for
Each rule asks for one of two things.
- Make sure someone reads this first. The note has to be ticked off before the change set goes ahead. If the rule names people, one of them ticks it. If it names nobody, whoever is reviewing can.
- Have specific people approve it. The people you name have to approve, and you choose how many: any one of them, everyone, or a set number. Same choices as approvals elsewhere in Mochi.
What happens when a rule is tripped
A change set that touches covered items waits. Its screen shows the rule's name and note above the list of changes, along with who it's waiting on, and the people you named get an email carrying the same note. Anyone on the “anyone else to tell” list is emailed too, and nothing is asked of them.
This happens whether or not the workspace asks for approvals generally. A rule is its own reason to pause a change set, so a workspace that doesn't review everything can still hold the handful of changes that deserve it.
Each rule is answered separately. If a change set trips two rules, both need answering, and approving one doesn't count toward the other. They're different questions for different people.
A rule is a snapshot once it's tripped
When a change set trips a rule, the name, the note and the list of people are copied onto that change set. Editing the rule afterwards changes what happens next time; it doesn't change what a change set already in review is waiting on. If a rule is deleted, change sets already waiting on it keep waiting, and the record of who answered stays.
Time limits
A rule that asks for approval can carry a time limit. Partway through, a reminder goes to the people who haven't answered yet. If the time runs out, the change set is turned down and can be proposed again. A change set with several time limits follows whichever is soonest, and gets that time back as each one is answered.
When a rule points at something that isn't there
A rule can name an item that later stops being tracked. The rule's screen flags that under Needs a look, and the list marks the rule too. It's worth acting on: somebody set that rule up believing it was covering that item, and a rule covering nothing is quiet in exactly the way a rule shouldn't be.