Workflows & Pipelines

Overview

Many activities in SARA are managed as records — purchase requests, purchase orders, trainings, vacation requests, quotes, maintenance records, and others. A record typically has:

A lifecycle — it is created, reviewed, updated, and eventually completed or cancelled.
One or more statuses to reflect its current step.
A workflow that defines how it moves between roles or departments.
Notes, logs, and notifications that provide traceability and transparency.

This page describes the common workflow concepts used throughout SARA. Individual feature pages reference this document and focus only on what is unique to that workflow.

Workflow types

SARA has two main types of record lifecycles. Every transaction follows one of these patterns (or a variation of them).

Pipeline workflows

Pipeline workflows are used for records that move through multiple steps involving different roles or departments — such as purchase requests, vacation requests, or quotes. A pipeline workflow typically follows this pattern:

Create — A user creates a new record by entering the minimum required information.
Review / validate — The record is reviewed by another role or department based on the workflow rules.
Decide — The reviewer may approve, reject, or return the record depending on its type.
Advance — If approved, the record moves to the next step (often another role or department).
Complete / archive — Once finalized, the record is considered completed and may appear in a processed or history view.
Cancel (optional) — Some workflows allow cancellation, typically only while the record is in an early status.

Fast creation, richer editing

Many transactions are designed so creation is quick and requires minimal information. After creation, editing the record reveals additional fields and options. This pattern applies across most transactions in SARA.

Catalog lifecycles

Catalog records — such as customers, suppliers, assets, or bank accounts — follow a simpler lifecycle. They do not go through approval pipelines. Instead, they are created in an active state and can be deactivated or reactivated as needed:

Create → record starts as ACTV (active).
Deactivate → record changes to INAC (inactive). It remains in the system for reference but is excluded from active operations (dropdowns, assignments, etc.).
Reactivate → record returns to ACTV.

Catalog records are never deleted — deactivation serves as a soft delete, preserving historical references and audit trails.

Note

Some catalog-type transactions may have additional statuses beyond ACTV and INAC to reflect data completeness or special conditions. These are documented in the feature's own workflow page.

Ownership and handoffs

In pipeline workflows involving multiple roles or departments, SARA uses an ownership model:

While a record is in a given step, the role or department responsible for that step "owns" it.
Once ownership is passed forward, the previous step typically cannot edit the record.
To make changes, the record may need to be returned to an earlier step (if the workflow allows it).

Note

The exact ownership rules vary by transaction, but the intent is consistent: prevent accidental changes while another person or department is actively working on the record.

Status-driven workflows

SARA uses statuses to represent the current step of a record. Statuses allow users to:

Quickly understand where a record is in the process.
Filter lists and dashboards by status.
Trigger the correct next actions (approve, reject, return, cancel, etc.).

Each transaction uses only a subset of SARA's status catalog, and each defines its own transition rules — which statuses can move to which, and who can trigger each transition.

For the full status catalog, see: Status

Edit rules by status

Every transaction defines which statuses allow editing and by whom. The general pattern is:

Early statuses (e.g., INPG, PEND) — Editable by the user or role that currently owns the record.
Review statuses (e.g., PEND in an approval step) — May be editable by the reviewer but not the original creator.
Terminal statuses (e.g., COMP, CANC, FINA) — Read-only for everyone.

The specific rules for each transaction are documented in that feature's workflow page.

Rejection and return

When a reviewer rejects a record in a pipeline workflow:

The record returns to a previous working status (e.g., PEND → INPG).
A rejection note is typically required to explain the reason.
The event is logged for audit purposes.
A notification is sent to the user responsible for the record.

Rejection is an event, not a permanent status — the record goes back to an editable state so the responsible user can address the feedback and resubmit.

Cancellation

Some workflows allow records to be cancelled, typically only while they are in an early status (before completion or finalization). When a record is cancelled:

The status changes to CANC.
A reason may be required.
The record remains in the system for reference but is no longer part of active operations.
Cancelled records are typically read-only.

Warning

Cancellation rules vary by transaction. Some records can only be cancelled in specific statuses, and some cancellations are irreversible. Check the feature's workflow page for the specific rules.

Logs, notes, and notifications

Logs & history

SARA records meaningful actions on records — creation, edits, approvals, rejections, status changes, and other events. This supports transparency, auditability, and traceability.

For details, see: Logs & History

Notes

Many workflows allow users to attach notes when making decisions or requesting changes. Notes typically exist to:

Explain context (why something was rejected or returned).
Provide instructions for the next step.
Preserve reasoning for future audits.

Notifications & alerts

Workflows often send notifications (email or WhatsApp) when a record changes status or requires attention. Notifications are generally aligned with workflow handoffs — the next responsible role is notified when action is required.

For details, see: Notifications & Alerts

Permissions define workflows

In SARA, workflows are strongly influenced by permissions:

Permissions determine which transactions a user can access.
Permissions determine which actions are available (create, edit, approve, reject, cancel, etc.).
Permissions can enable role-specific actions inside the same transaction (e.g., HR-only tools, admin panels).

Tip

If a user cannot perform an expected action, it is often due to missing permissions rather than a system error.

For permission management, see: Permissions & Access

Common workflow patterns

Approval workflows

A record is created by a requester and must be approved by one or more roles before it is finalized. The record moves through statuses like INPG → PEND → APPR or COMP.

Return-for-changes workflows

A reviewer rejects or returns a record so the requester can edit and resubmit it. The record cycles between working and review statuses until approved.

Multi-department pipelines

A record moves across multiple departments (handoff by status changes) until completion. Each department owns the record during their step.

Cancellation paths

A requester may be allowed to cancel the record, typically only in certain early statuses before the record has been approved or finalized.