Attaching lifecycles automatically

An entry receives its lifecycle from an automation. You set up one automation for each lifecycle: it checks every new entry against a rule and attaches the lifecycle to each entry that matches, starting it in the initial state. The person logging the entry has nothing to choose.

Event-triggered attachment

An automation that attaches a lifecycle is one of the shortest automations you can build. It has three parts:

• A trigger that fires on an event: a new entry being created.
• A condition on that trigger, which decides which new entries the automation acts on.
• A single step that attaches a lifecycle to an entry. You choose the lifecycle in the step's settings, and the trigger hands the step the entry that was just created.

Before you start, check that the lifecycle is finished and has an initial state. A lifecycle can only be attached once it has one, and every entry it reaches begins there. See designing a lifecycle.

To build the automation:

1. Create an automation and open it in the editor. Building an automation covers the editor itself.
2. Set its trigger to fire when an event happens, and choose the event for an entry being created. Triggers and schedules covers the trigger settings.
3. Add the condition that picks out the entries this lifecycle is for. The next section covers how to choose it.
4. Add the step that attaches a lifecycle, and choose your lifecycle in its settings.
5. Pass the new entry from the trigger into that step, so the step knows which entry to attach the lifecycle to.
6. Choose the service account the automation runs as. An automation with an event trigger cannot be switched on without one.
7. Save the automation and switch it on.

From then on, Pyron checks each new entry against the condition as it is created, whether someone logs it from a directory page, a form on a page or a shared form link. When an entry matches, the automation runs and attaches the lifecycle. The attachment happens just after the entry is saved rather than as part of saving it, so the entry's state appears a moment later.

A few things follow from this:

• Only new entries are checked, and only once, as they are created. Entries that existed before you switched the automation on stay as they are.
• Editing an entry never attaches a lifecycle, and never removes or swaps one the entry already carries, even when the edit means it would match a different rule.
• While the automation is switched off, nothing is checked. An entry created during that time stays without the lifecycle.
• The automation runs the version saved when you switched it on, so changes you make to it apply from the next time you switch it on.

The automation acts as its service account, not as the person who logged the entry. That account needs a role that lets it attach lifecycles to the entries in question. Without one, every run is refused and shows as failed. See service accounts and roles.

Choosing the matching rule

The condition is what makes the automation selective. It is a set of rules, and each rule compares one detail of the new entry with a value you give it. You pick the detail from the list the editor offers, such as the form the entry was filled in on or the place in the directory it was logged against, then a comparison, then the value.

The comparisons cover equal and not equal, contains, greater than and less than, whether the detail is one of a list of values, and whether the detail is empty. When a condition holds more than one rule, choose whether an entry must match all of them or any one of them. To mix the two, add a group of rules inside the condition: for example, entries on the incident form that were logged against either of two sites.

Keep these points in mind as you write the rules:

• Values are compared exactly. When the detail has a fixed set of options, the editor offers them as a list to pick from. When you type a value, it has to match exactly, including capitals and spaces.
• A not-equal comparison, and a not-in-the-list comparison, also match entries where the detail is empty. A greater-than or less-than comparison never matches an empty detail.
• An entry carries at most one lifecycle. If the conditions of two automations both match the same new entry, both try to attach their lifecycle: the entry keeps whichever attaches first, and the other run fails.

The surest way to keep conditions from overlapping is to test the same detail in each automation, with a different value in each. Suppose incidents and maintenance requests are logged on two separate forms. One automation attaches an Incident lifecycle when the form is the incident form, and a second attaches a Repair Request lifecycle when the form is the maintenance form. Each entry is filled in on exactly one form, so no entry can match both.

Checking it works

Try the automation with a pair of test entries before your team relies on it: one that should match and one that should not.

1. Open the lifecycle in the lifecycles workspace. The automations that use it are listed beneath its transitions, each with its status and whether it attaches the lifecycle or belongs to one of its actions. Check that your automation is listed and switched on.
2. Log a test entry that should match, from the place in the directory where such entries belong. See creating an entry.
3. Give it a moment, then find the entry in that page's entries table. A row with a lifecycle has its expand control tinted in the colour of its state. Expand the row to read the state by name: it should be the initial state of your lifecycle. See working a lifecycle.
4. Log a second test entry that should not match, and check that its row shows no state.
5. Open the automation's run history. The matching entry produced one completed run, and the other entry produced no run at all. See run history.

Both test entries also appear on the Entries screen, which gathers everything your team has logged. It is the quickest way to find them again if you lose track of where you logged them.

If no lifecycle appears

Start from run history, because whether a run exists tells you where to look.

• No run for the entry means the automation did not fire. Check that it is switched on, that the entry was created after you switched it on, and that the entry matches the condition value for value.
• A failed run means the automation fired but could not attach the lifecycle. Open the run to read its error. The usual causes are:
  • The service account the automation runs as has no role that lets it attach lifecycles to that entry.
  • The lifecycle has no initial state.
  • The entry already carries a lifecycle, because the condition of another automation matched it too.

Once the matching entry shows its initial state and the other shows none, the automation is ready. Every entry your team logs from then on that meets the condition starts its lifecycle on its own.