---
title: "Behavior of Workflow"
url: "https://help.tabidoo.cloud/en/article/behavior-of-workflow"
language: "en"
last_updated: "2026-03-09T13:12:38.733Z"
---

# Behavior of Workflow

Behavior of Workflow “Run As” Settings When Publishing the Application (DEV → PROD)

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 As**configuration. 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:

```plaintext
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

| Workflow Type | Behavior After Publishing | Risk | Recommendation |
| --- | --- | --- | --- |
| After Record Change | Switches to Logged-in User | May fail due to permissions | Use API Token |
| Button | Switches to Logged-in User | Often fails for regular users | Use API Token |
| Webhook | Switches to Logged-in User | Depends on caller permissions | Use API Token |
| Scheduled | Remains Run under Me (Owner) | Usually works | Use API Token for consistency |
| Time from Table | Remains Run under Me (Owner) | Usually works | Use API Token for consistency |

* * *

## 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.