Form Approval Workflows
When Aisha submits a deviation report on the packaging line, it cannot just land on a board and wait. The QA lead needs to review it. If the deviation is critical, the site director needs to sign off. If it affects a released batch, regulatory affairs must be notified. And every step of that chain needs to be documented for the next audit.
ProBeya approval workflows turn that chain into a visual, trackable, auditable process that runs automatically after each form submission.
Overview
An approval workflow is a directed graph of nodes and edges that defines who reviews a submission, in what order, and what happens after the final decision. You attach a workflow to a form, and every new submission enters the workflow automatically.
Approval workflows are useful when:
- Submissions require sign-off from one or more reviewers before they take effect
- Different submission types need different review paths (conditional branching)
- You need a documented audit trail of who approved what, when, and why
- Post-approval actions should fire automatically (create a project, send a notification, open a ticket)
- GxP regulations require authenticated e-signatures on review decisions
Creating a Flow
- Navigate to your project and open the Forms tab.
- Select the form you want to add an approval workflow to.
- Click the Approval Flows tab within the form.
- Click + Create Flow.
- Enter a name and optional description for the flow.
- If this form is part of a validated process, enable GxP Mode to require authenticated e-signatures.
- Click Create to open the visual flow editor.
The editor opens with a default start-to-end flow. You build your workflow by adding nodes between the start and end points and connecting them with edges.
Node Types
Start Node
Every flow has exactly one start node. This is the entry point where new submissions enter the workflow. You cannot delete or duplicate it.
Approval Node
The core of any workflow. An approval node pauses the submission and waits for one or more designated approvers to make a decision.
Configuration options:
| Setting | Description |
|---|---|
| Approvers | Select specific users or roles who can approve at this step |
| Approval type | Any (first response wins), All (unanimous required), or Sequential (ordered, one after another) |
| Deadline | Optional time limit. If no decision is made before the deadline, the request can auto-escalate or expire |
| Allow field edits | Whether the approver can modify submission values during review |
Condition Node
Routes the submission down different paths based on field values or previous decisions. For example:
- If GMP Classification = "Critical", route to the site director for additional approval
- If the previous approval was "rejected", route to the end node with a rejected status
- If the submission amount exceeds a threshold, add a finance review step
Conditions are evaluated automatically when the workflow reaches this node.
Action Node
Executes an automated action when the workflow reaches this point. Available actions:
| Action | What it does |
|---|---|
| Send email | Send a notification to a specific email address or the respondent |
| Create ticket | Create a support ticket from the submission data |
| Create Kaizen | Create a Kaizen improvement event linked to the submission |
| Create PPM project | Create a project in the PPM module from the submission |
End Node
Every flow must have at least one end node. End nodes mark the terminal state of the workflow. Each end node has a status: approved, rejected, or expired. A flow can have multiple end nodes to represent different outcomes.
Email Approval
Approvers can review and decide on submissions without logging into ProBeya.
Quick Mode
When a submission reaches an approval node, ProBeya sends an email to each designated approver. The email contains:
- A summary of the submission data
- Approve and Reject buttons that submit the decision with a single click
- An optional comment field
The approver clicks a button, and the decision is recorded. No login required. This is ideal for managers and external stakeholders who do not use ProBeya daily.
Full Mode
For approvers who want to review the full submission, the email includes a Review in ProBeya link that opens the submission detail page. From there, the approver can:
- View all submitted field values
- Edit field values (if allowed by the node configuration)
- Add a detailed comment
- Approve, reject, or return for revision
Token Security
Each approval email contains a cryptographically secure, single-use token. Tokens:
- Expire after a configurable period (default: 7 days)
- Can only be used once (prevents replay attacks)
- Are invalidated if the approval step has already been completed
- Record the IP address and user agent for audit trail purposes
GxP Mode
When a flow has GxP mode enabled, approval decisions carry the weight of electronic signatures under 21 CFR Part 11 and Annex 11.
What changes in GxP mode
| Aspect | Standard mode | GxP mode |
|---|---|---|
| Authentication | Email token or session | Authenticated login required |
| Audit trail | Standard activity log | Enhanced GxP audit entry with user ID, timestamp, IP, meaning of signature, and version snapshot link |
| Decision record | Stored in decisions table | Stored in decisions table + dedicated GxP audit log |
| Token-based approval | Available | Available with enhanced metadata capture (IP, user agent) |
| Version tracking | Optional | Every edit creates an immutable version snapshot |
How it works
- The approver receives an email notification about a pending decision.
- They click the link and are prompted to log in (or re-authenticate if already logged in).
- They review the submission data.
- They select their decision (approve, reject, or return for revision).
- The system records: their user ID, email, the timestamp, the meaning of the signature (the decision), and a link to the current version snapshot of the submission.
- This record is immutable and available for audit extraction.
Audit trail entries
Each GxP decision creates two log entries:
- Standard decision log (
form_approval_decision) — the decision itself with actor, node, and request references - GxP audit log (
form_approval_gxp_audit) — enhanced entry with all compliance-required metadata
Auditors can filter on entityType = "form_approval_gxp_audit" to extract only regulated decision records for inspection.
Post-Approval Actions
Action nodes let you trigger automated work when a submission passes through a specific point in the workflow. Common patterns:
- After final approval: create a PPM project to track the approved change request
- After final approval: send an email to the requestor confirming their submission was approved
- After rejection: send an email explaining why the submission was not approved
- After conditional branch: create a Kaizen event only for critical deviations
Actions are fire-and-forget — if an action fails (e.g., email delivery issue), the workflow continues. The failure is logged for troubleshooting.
Monitoring
Approval Tracker
The flow detail page shows a dashboard with:
- Request counts by status — pending, in progress, approved, rejected, expired
- Timeline — chronological list of all decisions made across all requests
- Active requests — paginated list of in-flight approval requests with their current step highlighted on the flow graph
Version History
Each submission maintains a complete version history. Every edit (by the respondent or an approver) creates a new version snapshot with:
- Version number
- Who made the change (user ID or email)
- When the change was made
- Why (change reason)
- The full field values at that point in time
This enables full diff and rollback capabilities for audit trail review.
Best Practices
- Keep flows simple. A three-step linear flow (submit, review, approve) covers 80% of use cases. Save complex branching for genuinely conditional processes.
- Use GxP mode only when required. The additional authentication step adds friction. Reserve it for regulated processes where electronic signatures are mandated.
- Set deadlines on approval nodes. Without deadlines, forgotten approvals can block submissions indefinitely. A 5-day deadline with email reminders keeps the process moving.
- Test the flow before activating. Use the flow editor's validation feature to check for orphan nodes, missing connections, and unreachable end states.
- Only one active flow per form. ProBeya enforces this automatically — activating a new flow deactivates the previous one.
Troubleshooting
| Problem | Solution |
|---|---|
| Approver did not receive email | Check the approver's email address in the node configuration. Verify your email delivery service (Resend) is configured. |
| Token expired before approver could decide | Increase the token expiry duration in the flow settings, or send a reminder. |
| Flow cannot be activated | The flow editor shows validation errors. Fix unreachable nodes or missing connections before activating. |
| Cannot delete a flow | Flows with active (pending/in_progress) requests cannot be deleted. Complete or cancel the requests first. |
| GxP audit entry not appearing | Verify that GxP mode is enabled on the flow (not just the form). Check the activity log for form_approval_gxp_audit entries. |