Running Processes

Find and diagnose a case

Start broad, then filter by design, entity type, state, initiator, or age. A design filter isolates one lifecycle, while state and age help find work that may be stalled. Open the process when you need more than a list value: its history, tasks, evidence, and dwell time explain the current position.

To resolve a stalled case, confirm the state, identify required work, check its assignment and due date, then review the most recent transition and evidence. Complete or claim work if authorized, and take the defined transition once the outcome is known. If normal work cannot continue, use the configured exception, cancellation, or failed path.

No available action can be intentional. A role, rule, form, required task, or the actual current state can restrict it. Ask an administrator to review the design rather than attempting to bypass the lifecycle.

Evidence and history

Use attachments for documents and concise references for records held elsewhere, such as approval IDs, service tickets, test runs, or shipment confirmations. The evidence manifest provides an inventory of attachments. See Evidence and audit for recording guidance.

Open Processes from the primary navigation to find active process instances. Filter by design, entity/process type, current state, initiator, or age, then select a row to open its details.

Process details

The detail page brings the working context together:

• the process ID, design, related entity, current state, initiator, and start time;
• actions currently authorized for you;
• process tasks, their assignments, due dates, priority, and completion evidence;
• attachments and an exportable evidence manifest;
• state-change history, dwell time, and the state-machine diagram.

The available actions are loaded from PROCESS.API when the page opens. The API validates permission, current state, rules, required comments, and forms again when an action is submitted. Seeing an action in the browser is not an authorization grant.

Links in process emails and notifications may open Process Work, a focused page for the action, approvals, and tasks currently available to the signed-in recipient. Use the detail page when you need the full history, evidence, diagram, or all available actions.

An administrator can assign an open task to a supplier or partner through an external work request. The process detail page shows when that request was viewed and how the recipient responded. Only a confirmed response completes the task. See External Work for response behavior and link security.

Moving a process forward

Select an available action, provide its requested comment or evidence reference, complete any required form fields, and submit. After a successful transition, the page refreshes its action list and diagram.

Use explicit exception, cancellation, or failed states when normal work cannot continue. Do not treat an email, notification, or an external system call as proof that work was completed; record a verified outcome before making the next transition.

Read The Process Header

Confirm the design and related entity before making a change, especially when several processes have similar names. The process ID identifies this lifecycle instance; the entity ID identifies the business record in the source application. The initiator shows who started the process, but that person is not necessarily the current owner.

The current state describes the business condition now. State ownership identifies the accountable person or role. A task assignment identifies who should perform a particular piece of work. These values can differ deliberately: one person can own the state while a specialist completes a task.

Investigate A Delayed Process

Use the following sequence so the investigation remains tied to evidence:

1. Confirm how long the process has occupied its current state.
2. Review every open task, including assignment, priority, due date, and claim status.
3. Read the most recent history entries to learn how the case arrived here.
4. Check forms, attachments, and references for missing or conflicting information.
5. Identify the person or role accountable for the next outcome.
6. Use the configured escalation or exception route when the normal outcome cannot be reached.

A long dwell time is a signal, not proof of neglect. The case may be waiting for a contractual date, customer response, external shipment, or other valid dependency. Record that context in the appropriate task or process evidence so the next reviewer does not have to rediscover it.

Understand Changes Made By Other People

PROCESS validates an action at submission time. If another person moves the case while your page is open, your action can be rejected because its expected state is no longer current. Reload the process and review the new state rather than repeating the submission. Similarly, an item can disappear from a queue after it is claimed, completed, reassigned, or made irrelevant by a transition.

For audit questions, read history and evidence together. History establishes who changed the lifecycle and when. Evidence, form responses, and notes explain the business basis for that change.