Behavior of Workflow

When working with workflows in Tabidoo, the Run As setting determines under which user permissions a workflow is executed.

After publishing an application from DEV to PROD, some workflow triggers may automatically change their Run Asconfiguration. This can cause workflows to behave differently or stop working due to permission restrictions.

This article explains:

• how the Run As options work
• what happens after publishing an application
• why workflows sometimes stop working
• how to configure workflows to ensure consistent behavior

Run As Options in Server Workflows

Server-side workflows can run under three different authorization contexts.

Run under Logged-in User

The workflow runs under the permissions of the user who triggered the action.

Use cases:

• user-specific logic
• actions that should respect the user's permissions

Risk:

If users have limited permissions, the workflow may fail.

Run under Me (Workflow Owner)

The workflow always runs under a specific user account.

Behavior differs between environments:

DEV

The workflow runs under the user who created the workflow.

PROD

The workflow runs under the application owner (the user who owns or imported the application).

Use cases:

• system workflows
• workflows that should not depend on the triggering user's permissions

Limitation:

This behavior is not consistent across all workflow triggers.

Run under API Token

The workflow runs under a predefined API Token identity.

Advantages:

• independent of the triggering user
• consistent across environments
• easier to manage permissions

This is the most stable and recommended configuration.

Workflow Behavior After Publishing

When an application is published from DEV to PROD, some workflows automatically change their Run As configuration.

This happens because Tabidoo distinguishes between:

• user-initiated workflows
• system-initiated workflows

User-Initiated Workflows

These workflows are triggered directly by a user action.

Examples:

• After Record Change
• Button
• Webhook

Behavior after publishing:

The Run As setting automatically switches to:

Run under Logged-in User

Reason:

Because these workflows are triggered by a user action, the system assumes the workflow should respect the permissions of that user.

Potential issue:

If users in PROD have limited permissions, the workflow may stop working.

System-Initiated Workflows

These workflows are triggered automatically by the system.

Examples:

• Scheduled workflows
• Time from Table workflows

Behavior after publishing:

The workflow remains set to Run under Me.

In PROD, “Me” becomes the application owner.

Reason:

These workflows are not triggered by a specific user action, so they run under a system-level identity.

Why This Can Cause Problems

Because workflow triggers behave differently after publishing:

• some workflows switch to Logged-in User
• others remain Run under Me

This creates inconsistent behavior between DEV and PROD.

Common issues include:

• workflows failing due to insufficient permissions
• workflows working in DEV but failing in PROD
• the need to manually fix workflow settings after every deployment

Recommended Setup for Stable Workflow Execution

To ensure workflows behave consistently across environments, it is recommended to use an API Token for workflow execution.

This prevents workflows from switching authorization context during deployment.

Step 1 — Create Workflow Roles in DEV and PROD

Create one workflow role in each environment.

In the DEV application

Create a role named:

WORKFLOW_DEV

In the PROD application

Create a role named:

WORKFLOW_PROD

Both roles should have identical permissions.

Because DEV and PROD are separate applications, roles are separate objects and must be created independently in each environment.

Step 2 — Create a Shared API Token

Create a dedicated API Token that will execute workflows.

Example:

WorkflowRunner

Assign both roles to this token:

• WORKFLOW_DEV (from the DEV application)
• WORKFLOW_PROD (from the PROD application)

This ensures the API token has the correct permissions in both environments.

Step 3 — Configure Workflows to Run Under the API Token

For every workflow, set:

Run As → API Token

This configuration is recommended for all workflow types:

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

How the Setup Works

The API Token acts as a shared execution identity used by workflows in both environments.

DEV and PROD workflows use the same token, but the token receives permissions through environment-specific roles.

Diagram:

DEV application
  └ WORKFLOW_DEV role
         │
         ▼
     API Token
         ▲
         │
PROD application
  └ WORKFLOW_PROD role

Note

In most cases, you do not need to manually create a second role in the PROD application.

When an application is published from DEV to PROD, roles created in DEV are automatically transferred to the PROD application together with the application structure.

This means that after deployment, the same role already exists in the PROD application.
You only need to assign this role to the API Token in the PROD environment.

Example:

DEV application
Role: WORKFLOW_DEV

After publishing → the same role exists in PROD.

In PROD, simply assign this role to the API Token.

Workflow Behavior Summary

Final Recommendation

For stable workflow behavior after every deployment:

• Create matching workflow roles in DEV and PROD.
• Create a shared API Token.
• Assign both roles to the token.
• Configure all workflows to Run under API Token.

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