Enterprise Workflows

Concept

Entity Lifecycle, Built-in Tasks and BPMN 2.0 workflows are concept features. They're still being developed and can change before they're released. Built-in Tasks is available only when the site's license includes the Concept feature Tasks, and BPMN 2.0 workflows only when it includes Bpmn2.

Audience: Low-code Engineers

Skill Prerequisites: Entities, Workflows

General Description

Business processes such as approvals, orders and reviews have three things in common: a record that moves through steps, people who have work to do at some of those steps, and a process that runs for days and waits in between. Three features cover them, and they're designed to work together:

Feature	What it adds	Where you set it up
Entity Lifecycle	A State property with states and transitions. The platform keeps every record in a valid state, adds the transition buttons to the generated pages, and can record the history of every record.	The Lifecycle and History tabs of an entity.
Built-in Tasks	Work that waits for a person, with assignees, candidate roles, due dates, escalation and one list for everyone: My Tasks.	Configuration > Tasks, and Tasks on entry on a lifecycle state.
BPMN 2.0 workflows	Workflows whose diagram runs on the server, with loops, errors, and steps that wait for a timer, an event, a called workflow or a task.	The workflow editor, after upgrading a workflow to BPMN 2.0.

You can use each feature on its own. Use them together when a process needs more than one of them.

Choosing a Feature

You need to	Use
Know where a record stands, and let only some people move it on	Entity Lifecycle
Know who changed a record, when, and what changed	Record History
Let a role read, edit or delete only some records while they're in a state	Permissions by state
Give a person or a team something to do, with a due date	Built-in Tasks
Give a record a set of tasks when it enters a state, and move it on when they're done	Checklists on Lifecycle States
Run a process that waits for hours or days, for a timer, an event or a person	BPMN 2.0 workflows

How They Work Together

The pages of all three features use one example: purchase requests. A Purchase Request entity has a State property, a Tasks property of type List of Tasks, and a few fields such as Supplier, Amount, Rejection Reason, PO Number and Expected Delivery. Employees, Line Managers, Buyers, Procurement Leads and Finance Controllers work on it.

1. The lifecycle. A request starts in Draft and moves through Submitted, Approved, Ordered and Received to Closed. Employees Submit, Line Managers Approve or Reject, and a rejection needs a Rejection Reason. Field rules make the request read-only once it's submitted. See Entity Lifecycle.
2. A checklist on Submitted. When a request enters Submitted, its checklist creates two Purchase check tasks: the Buyers check the supplier, and, for amounts over 5,000, the Finance Controllers check the budget. Approve is refused while either is open. See Checklists on Lifecycle States.
3. My Tasks. The checks appear in My Tasks for the members of those roles. One of them assigns a check to themselves and completes it as Looks fine, or as Concern with a comment. See My Tasks.
4. Approval starts a process. The After workflow of Approve raises the event Purchase request approved with the Raise Event action. That event starts a run of the BPMN 2.0 workflow Purchase follow-up for the request. See Running Transitions and Timers, Events and Waiting.
5. Ordering. On Approved, the Buyers get a Purchase order task. They fill in the PO Number and Expected Delivery in the task panel and complete it, and the checklist runs Order. If the task is late, its escalation steps raise its priority and then hand it to the Procurement Leads. See Due Dates, Escalation and Events.
6. The process waits. Purchase follow-up waits for the request to be ordered, then for the delivery. If the goods aren't received in time, it asks the Procurement Leads to chase the supplier. For large amounts, it asks Finance to book the invoice and waits until they have. Then it runs Close. See Designing BPMN 2.0 Workflows.
7. The trail. Every transition, with its comment and the fields it changed, is in the request's History tab. Waiting runs are in Workflows > History, where you can cancel one. See Record History and Workflow History.

A task can also be a step of the process itself: a BPMN 2.0 user task creates a task and waits until someone completes it.

Plans and Licensing

Feature	Needs
Entity Lifecycle: the State property, transitions, field rules, the generated buttons, actions and API, Before and After workflows	Every plan.
Record History	Lifecycle.History, part of the Enterprise plan.
Permissions by state	Lifecycle.Permissions, part of the Enterprise plan.
The transition contract in the Before and After workflow pickers, and your own workflows on the Task Event and Task Escalation contracts	Workflows.Contracts, part of the Enterprise plan.
Built-in Tasks, including checklists, escalation steps and event workflows	The Concept feature Tasks.
BPMN 2.0 workflows, the Raise Event and Throw Error actions	The Concept feature Bpmn2.
A BPMN 2.0 run that waits, and a workflow that starts on an event	Workflows.LongRunning, part of the Enterprise plan.
User tasks	Bpmn2, Tasks and Workflows.LongRunning.

Considerations

• Concept features change. Labels, settings and messages on these pages can change before the features are released. Try them on a development site first.
• Not everything is in yet. Each page's Considerations say what isn't available yet where you'd look for it. For example, Record History doesn't record changes to related records, a user task can't have a timer on its border, and a failed run can be cancelled but not retried.
• One example everywhere. Names such as Purchase check or Purchase follow-up are the example's, not built-in names. The only built-in task type is General.

Related Pages

• Entities
• Workflows Overview
• Contracts
• Tasks actions

Revised 11/12/2026