Skip to content

Workflows & Pipelines

Overview

Many activities in SARA are managed as records (for example: purchase requests, purchase orders, trainings, vacation requests, 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 / pipeline 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 process pages reference this document and focus only on what is unique to that workflow.

Record lifecycle (common pattern)

Most records in SARA follow a lifecycle similar to:

  1. Create
    • A user creates a new record by entering the minimum required information needed to start the process.
  2. Review / Validate
    • The record is reviewed by another role (or department) based on the workflow rules.
  3. Decide
    • The reviewer may approve, reject, return, or request changes depending on the record type.
  4. Advance
    • If approved, the record moves to the next step (often another role or department).
  5. Complete / Archive
    • Once finalized, the record is considered completed and may appear in a processed/history view.
  6. Cancel (optional)
    • Some workflows allow the requester to cancel a record, depending on its status.

Fast creation, richer editing

Many transactions are designed so creation is quick and requires minimal information.
After creation, editing the record often reveals additional fields and options.

Ownership and handoffs

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

  • While a record is in a given step, the role/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, etc.)

Info

Status labels are displayed in the UI (often as short codes).
For system-wide guidance on statuses, see: Status

Logs, notes, and notifications

Logs & history

SARA records meaningful actions on records (for example: creation, edits, approvals, rejections, status changes).
This supports:

  • Transparency: clarity on what happened and when
  • Auditability: ability to review and confirm decisions
  • Traceability: identifying who changed what and why

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 email notifications when a record changes status or requires attention.
For details, see: Notifications & Alerts

Note

Not every transaction uses the same notifications, but notifications are generally aligned with workflow handoffs (the next responsible role is notified when action is required).

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 (for example, HR-only tools).

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: Control Panel

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.

Return-for-changes workflows

A reviewer rejects or returns a record so the requester can edit and resubmit it.

Multi-department pipelines

A record moves across multiple departments (handoff by status changes) until completion.

Cancellation paths

A requester may be allowed to cancel the record (often only in certain statuses).