Behavior of Workflow

When working with workflows in Tabidoo, you may notice that the Run As configuration behaves inconsistently after publishing your application from DEV to PROD.
Based on the recent meeting, here is the clarified and unified explanation of how the system works and how to avoid issues.

Run As Options in Server Workflows

Server-side workflows can run under different authorization contexts.
There are three available modes:

Run under Logged-in User

The workflow executes under the permissions of the user who triggered the action.
➡️ Useful for user-specific logic.
❗ Risky when permissions vary across users.

Run under Me (Current User)

The workflow always runs under a fixed user account.

• In DEV: the creator of the workflow
• In PROD: the owner of the application
  ➡️ Stable for system workflows, but not unified across triggers.

Run under API Token

The workflow uses a predefined API Token with dedicated permissions.
➡️ The most consistent and secure option.
➡️ Works independently of the user who triggered the action.

Workflow Behavior After Publishing

Why Some Workflows Change “Run As” Automatically

During the meeting, you identified a key issue:

• In DEV, all workflows start as Run under Me (the creator).
• After importing the application to PROD:
  • After Record Change, Button, and Webhook workflows automatically switch to Run under Logged-in User.
  • Scheduled and Time from Table workflows remain set to Run under Me, but the user becomes the owner of the application.

This leads to inconsistent behavior and often causes workflows to stop working due to role restrictions.

Below is the official reasoning:

Why the Behavior is Not Unified

Different workflow triggers are classified as either user-initiated or system-initiated.

User-Initiated Workflows

(After Record Change, Button, Webhook)

• Automatically switch to Run under Logged-in User after publishing.
• Reason:
  These workflows are triggered directly by a user action, so the system assumes the workflow should respect that user’s permissions.
• Issue:
  If users in PROD have limited roles, the workflow may fail.

System-Initiated Workflows

(Scheduled, Time from Table)

• Remain set to Run under Me.
• In PROD, “Me” becomes the application owner.
• Reason:
  These workflows are triggered by the system, not by a specific user.

Risks and Limitations

This default design causes confusion because:

• The first three workflow types change behavior when the app is published.
• Some workflows break when run by users with insufficient permissions.
• The logic is not unified across all triggers.

Best Practice: How to Ensure Consistent Behavior

To avoid reconfiguring workflows after every deployment and to ensure they work reliably in both DEV and PROD:

1. Create Matching Roles in DEV and PROD

Example:

• WORKFLOW_DEV
• WORKFLOW_PROD

These roles must have identical permissions.

2. Create a Shared API Token

Example: WorkflowRunner.

Assign both roles (DEV and PROD equivalents) to this token.

3. Set All Workflows to “Run under API Token”

Recommended for:

• After Record Change
• Button
• Webhook
• Scheduled
• Time from Table

➡️ This unifies the behavior for all workflow types.
➡️ Prevents switching to “Logged-in User” when publishing.
➡️ Eliminates issues caused by user permissions.

Summary Table

Final Recommendation

To ensure stable workflows after every deployment:

• Always define matching roles in both DEV and PROD.
• Use a shared API Token assigned to both roles.
• Configure all workflows to Run under API Token.

This guarantees consistent, secure, and predictable workflow execution across environments without manual adjustments after publishing.