Lifecycles

A lifecycle (blueprint) defines an entity's statuses and the transitions between them. When lifecycle support is on:

• New records get a lifecycle chosen by criteria, or the default one, and start in its default status.
• GET /api/v1/status/available returns the transitions the current user may take, after filters and validators.
• PUT /api/v1/status/update moves the record, runs the transition's validators (including custom C# validators), records history with SLA fields, and starts the workflows configured to run after the transition.
• Many records can move at once with POST /api/v1/status/bulk-update.

Blueprints

A Blueprint is the platform's state machine for records such as tasks, projects or expense requests. It has five parts:

A new record starts in the Blueprint's default status. Its current status is stored in its record info, and the detail screen shows a status dropdown listing only the transitions allowed from that status (the screen's DSQ must include recordinfo.blueprintid).

Create a Blueprint

1. Go to Administration > Automation > Blueprint and choose Add Blueprint. In TAF Studio, run TAF: New Lifecycle.
2. Enter a name, select the AppObject and add a description. Use the criteria builder to say which records the Blueprint applies to, for example only work items of type Recruitment, or only fixed-cost projects. One entity can have several Blueprints for different kinds of record.
3. Save. The Blueprint designer opens. Add statuses with Add Status, drag them onto the canvas, and give each a colour and a sequence. Mark exactly one as the default.
4. Connect two statuses by dragging a line between them, and name the transition in the popup. Studio's Add Status to Lifecycle and Add Transition to Lifecycle do the same, and let you edit the lifecycle as a diagram.

Transitions

Each transition has three phases:

• Before: checks that run before the status changes, such as validating that the user holds an allowed role, team or user. If the check fails, the move is not offered to that user.
• During: what the user sees while moving the record, such as a screen to fill in (a rejection reason, for example) or a message.
• After: what happens once the move completes, typically running one or more workflows that update data or send notifications.

The Transitions tab in the Blueprint settings lists every transition so you can open and edit its phases. Stored, a transition's phases look like this; here only managers may make the move, and a workflow runs afterwards:

{
  "TransitionHooks_Before": {
    "Actions": [
      {
        "ActionType": "ValidateUserCriteria",
        "Config": {
          "AllowedRoles": ["<Manager role id>"],
          "AllowedTeams": [],
          "AllowedUsers": []
        }
      }
    ],
    "Filters": null
  },
  "TransitionHooks_During": { "Actions": [] },
  "TransitionHooks_After": { "Actions": ["<workflow id>"] }
}

Records can be moved one at a time from the detail screen, or many at once: a bulk status update applies the same transition rules to each record and reports which records moved and why any did not.

SLAs

Open the Blueprint's Settings tab and use SLA Management to choose Add SLA. Set the measuring mode, the criteria for when the SLA applies (for example when a task enters In Progress) and the target, such as “complete within 2 hours”. Record info tracks the SLA that applies to each record, so you can monitor whether transitions meet their targets. In Studio, use TAF: SLA Configuration.

Approvals

An approval process asks one or more people to decide on a record before it counts, with the routing configured as data rather than code. Turn on approval support for the entity, then define the process (in Studio, TAF: Approvals).

The process

• Applies to one AppObject, with criteria that decide which records it covers. When several processes match, their sequence decides which one runs.
• Manual submit controls whether users may submit a record for approval themselves.
• Auto-approve criteria let routine cases pass without a decision.
• A process is drafted, then published. Only published processes start requests, and each request remembers the version it started on.

Levels and approvers

A process has one or more levels, decided in order. Each level has a routing mode, a quorum (how many approvals are needed), optional skip criteria and a fallback approver. Approvers at a level can be:

Amount bands or other matrices can route requests to different approvers, for example a manager for small claims and Finance above a threshold.

Decisions

Approvers can approve, reject, return the record to the requester, delegate, reassign or comment, and requesters can recall. Reject, return and comment require a comment. Each decision is kept as a record, so the history of who decided what, and when, stays with the request. Delegation rules let someone hand their approvals to another person.

The inbox

Every approval step assigned to a person appears in their inbox, alongside mentions from comments. Opening an item takes the approver to the step, where they decide. A scheduled deadline sweep sends reminders and then escalations for steps that are overdue.

Lifecycle or approval?

• Use a lifecycle transition when one person moves a record to its next status, even if only some roles may do it.
• Use an approval process when other people must decide, in levels, with quorum, delegation or deadlines.
• They work together: a lifecycle tracks where the record is; an approval decides whether it may go on.

To run automation when a status changes, attach workflows to the After phase. See Workflows and jobs and Notifications.