Building a Multi-Step Approval Workflow in Bubble Without Plugins: A Complete Native Architecture

Build a multi-step approval workflow in Bubble by storing requests, approval steps, and templates in the database. Use workflows and triggers to route each request, record decisions, notify users, and handle exceptions without plugins.

Understanding the Native Approval Architecture

Start with a data model that separates the request from its approval steps. This keeps status changes visible, makes individual decisions auditable, and gives you control over routing rules.

Use these core data types:

Request — The primary record for an expense report, content draft, purchase request, or other item requiring approval. Store its current status and the active approval step.

Approval Step — A record for each decision in the chain. Link it to the request, an assigned user, an order, and a decision status.

Approval Template — An optional reusable definition of approval stages. A template might route an expense to a manager and then to finance when the requested amount meets your condition.

A request has many approval steps, while each approval step belongs to one request. Keep routing and status changes in the database rather than storing them only in page elements.

Configuring the Database

Request Data Type Fields

Add fields for the information your application needs, plus:

• Status: Use clear values such as draft, pending approval, approved, rejected, and recalled.
• Current Step: Identifies the active stage.
• Total Steps: Identifies the final stage.
• Approval Steps: A list of the request’s approval-step records.
• Submitted By: The user who submitted the request.
• Submitted Date: The submission date and time.

Choose status values that describe your business process. Avoid adding values that your workflow does not handle.

Approval Step Data Type Fields

Each step should contain:

• Request: The parent request.
• Step Order: The position of the step in the sequence.
• Approver: The assigned user.
• Status: Use values such as waiting, pending, approved, rejected, and skipped.
• Decision Date: When the approver acted.
• Comments: Feedback from the approver.
• Delegated To: An optional replacement approver.

Keep the decision information on the approval-step record. This makes it easier to review the history of a request later.

Approval Template Data Type

For repeatable approval paths, create:

• Template Name: A readable identifier.
• Steps: A list of template-step records.
• Department: An optional routing category.
• Conditions: Fields that determine when the template applies.

You can select a template when a request is submitted. Alternatively, create its approval steps directly from rules stored on the request.

Building the Approval Workflow Logic

Request Submission

When a user submits a request:

1. Create the required approval-step records.
2. Assign the appropriate approver to each step.
3. Set the request status to pending approval.
4. Set the current step to the first active stage.
5. Notify the first approver.
6. Start any follow-up workflow needed for escalation or reminders.

If the application needs to create a long sequence of steps, process the list in smaller batches through scheduled backend workflows. This keeps the submission workflow easier to follow and reduces the amount of work performed in one run.

Approver Decision Processing

When an approver approves or rejects a step:

1. Update that approval-step record with the decision, date, and comments.
2. Use a database trigger or related workflow to evaluate the request.
3. Apply the appropriate status change.
4. Notify the next person who needs to act.

Use this decision logic:

• Rejected step: Set the request to rejected and notify the submitter. Leave later steps unchanged, but prevent them from being actioned.
• Approved final step: Set the request to approved and run any agreed follow-up actions.
• Approved non-final step: Advance the current step and notify the next approver.

Make sure that a decision can only change the request when the selected step is still the active step. This prevents an old or duplicate decision from advancing the workflow again.

Handling Edge Cases

Approval delegation: Add a delegation action for the current approver. Store the replacement user, update the step, and use that field when sending reminders or escalation notices.

Parallel approval: Create multiple records for the same stage when several people must approve it. Advance the request only when the required records for that stage meet your approval rule.

Timeout escalation: Schedule a follow-up when a step becomes pending. When the follow-up runs, check the step’s current status before escalating it. If someone has already acted, do not send another escalation.

Repeated approvers: Decide whether the same person may approve several stages. If not, validate the template before creating steps and show the submitter which routing rules were applied.

Withdrawn requests: Let the submitter withdraw a pending request when your process allows it. Set the request status to recalled, block further decisions, and record the reason.

Designing the User Interface

Submitter Dashboard

Create a repeating group showing requests submitted by the current user. Display:

• The request title and submission date.
• The current status.
• The active stage and total stages.
• The decision history and comments.
• A link to the full request.

Use plain labels for status rather than relying only on colour. A submitter should be able to understand what happened without interpreting the interface.

Approver Queue

Show pending approval steps assigned to the current user. Include:

• Enough request context to make a decision.
• Separate approve and reject actions.
• A comments field.
• Clear confirmation before a decision is submitted.
• A way to delegate the step when permitted.

Do not let the interface display an approval action after the step is no longer pending. Recheck the step’s status when the user submits the decision.

Conditional Visibility

Use conditional display rules to show actions only when they apply:

• Show approve and reject actions when the current user is assigned to the pending step.
• Show delegation options only when delegation is allowed.
• Show withdrawal actions only to the submitter and only while the request can still be recalled.

Keep these conditions consistent with the workflow. If the page allows an action, the backend logic must verify the same conditions.

Implementing Notifications

Create notification records with fields such as:

• Recipient
• Message
• Related Request
• Is Read
• Created Date

When a request is submitted, a step becomes active, a decision is recorded, or a request changes status, create a notification for the relevant user. Link the notification to the request so the recipient can open the correct page.

Use email when users need an external reminder. Include:

• The request title.
• The submitter’s name.
• A link to the relevant approval page.
• The current stage and comments.
• A clear statement of the action required.

When a user opens the notification, verify access to the linked request before displaying its contents.

Testing and Debugging Your Native Approval System

Test the workflow from submission through the final decision. Include failed decisions, delegation, withdrawal, repeated approvers, and reassignment.

Step-by-Step Testing Protocol

1. Test each workflow separately: Confirm that submission, approval, rejection, and follow-up actions produce the intended records and status changes.
2. Test database triggers: Change a step status in a development environment and verify the resulting request changes.
3. Run complete approval paths: Use test users to follow each supported template from submission to completion.
4. Test edge cases: Check recalled requests, inactive approvers, duplicate decisions, and requests with parallel stages.
5. Check permissions: Confirm that users can see only the requests and steps they are allowed to access.
6. Review execution behaviour: Watch for loops, repeated notifications, and workflows that continue after the relevant status has changed.

Common Pitfalls and Solutions

Infinite recursion: If a workflow changes a field that starts the same workflow, add a guard condition. Check the current status before continuing and prevent processing when the request is already in a terminal state.

Privacy conflicts: Review the database’s privacy rules for submitter, approver, administrator, and template access. Test the interface as each relevant user role.

Duplicate actions: Require the step to be pending when a decision is submitted. Ignore or reject repeated decisions once the step has changed status.

Inconsistent routing: Store the approval steps created for each request. Use those records to determine who acts next instead of recalculating the entire route each time.

Unclear audit history: Record the decision, approver, comments, and date on every completed step. Avoid replacing old approval records when routing changes.

FAQ

How should I handle a long approval chain?

Break the chain into smaller scheduled workflow runs when necessary. Test the resulting request behaviour and make sure users can see which stage is active and who needs to act.

Can I route requests based on request data?

Yes. Select a template or create approval steps using conditions based on fields such as department, request type, amount, or location. Keep the routing rule visible to administrators so they can understand why a path was created.

What happens when an approver leaves?

Create an administrative reassignment workflow. When an approver is deactivated, find their pending steps, assign replacements, and notify the new approvers. Define whether the original approver’s completed decisions remain valid.

How do I prevent a user from approving the same request twice?

Check the approval step and request status when the decision is submitted. Only process the action if the step is pending and belongs to the request’s current stage.

How do I let a submitter track progress?

Display the request’s status, active stage, total stages, and completed decisions. Provide a history view that shows each approver’s decision and comments.

Final Checklist

Before publishing the workflow, confirm that:

• The request and approval-step relationships are correct.
• Every status has a defined next action.
• Only the assigned approver can act on a pending step.
• Completed decisions cannot be changed by normal user actions.
• Rejected, recalled, and approved requests cannot advance.
• Parallel stages advance only when your rule is satisfied.
• Delegation and reassignment update the correct records.
• Notifications point users to the relevant request.
• Privacy rules match your access requirements.
• You have tested the complete workflow and its exception paths.