White label & Multi-tenancy

Overview

This page is meant for partner developers integrating Voodflow into a third-party white-label application.

White-label mode is about product governance and safety. It helps you build a platform where:

• You ship platform-managed workflows that end-users cannot accidentally break.
• End-users can still create their own workflows, within a sandbox you control.

Core idea: two workflow “classes”

In a typical white-label setup you will have two categories of workflows.

Platform-managed (structural) workflows

These workflows are created by a platform admin and represent product-level automation:

• They implement business processes that must remain stable.
• They can be shared across many tenants.
• End-users influence behavior via their own data and settings, not by editing the graph.

Examples:

• Order lifecycle automations (sync, auditing, notifications, webhooks)
• Compliance workflows (validation, policy enforcement, record creation)
• Scheduled operations (exports, reconciliations)

End-user workflows

These workflows are created by end-users (or tenant admins) and are meant to be flexible, but controlled:

• Tenants can tailor automations to their needs.
• The platform can restrict dangerous capabilities via node-level policy.

Examples:

• “When a lead is created, assign it, enrich it, then notify the sales team”
• “When a form is submitted, call an internal webhook and store a record”

What Voodflow enforces (white-label mode)

When white-label mode is enabled (VOODFLOW_WHITELABEL_ENABLED=true), Voodflow focuses on control and safety.

Node denylist (admin-configured)

• Blocked node types are hidden from end-users in the editor.
• End-users cannot save/import/update a workflow that contains blocked node types.
• Restrictions are enforced server-side, not only in the UI.

This is the mechanism you use to sandbox end-user workflows.

Workflow visibility and ownership

• In non-tenant mode, end-users can only view workflows that belong to them (user_id).
• In tenant mode, end-users can only view workflows that belong to their tenant.
• Global admins can view everything and may bypass denylist rules.

Tenant scoping (non-tenant vs tenant)

Two modes are supported:

Non-tenant

• Use the existing user_id ownership model.
• End-users only see and edit their own workflows.

Tenant (optional)

• Enable VOODFLOW_TENANCY_ENABLED=true.
• Voodflow uses tenant_id columns when present.
• During execution, Voodflow sets a runtime tenant context so the host app can scope queries correctly.

Environment variables

Variable	Type	Purpose
VOODFLOW_WHITELABEL_ENABLED	boolean	Enables end-user node blocking and white-label protections
VOODFLOW_TENANCY_ENABLED	boolean	Enables tenant-aware scoping (requires tenant columns to exist)

Exposing host-app data to workflows (developer-side)

Voodflow does not know your domain concepts (channels, preferences, plans, integrations). In a white-label product you typically want workflows to read tenant/user data safely and scoped.

Tenant scoping via runtime context (recommended)

Voodflow sets a runtime tenant context during execution. In your models, apply a global scope based on:

• Voodflow\Voodflow\Support\TenantContext::getTenantId()

Conceptual example:

use Voodflow\Voodflow\Support\TenantContext;

$tenantId = TenantContext::getTenantId();
// Apply `where('tenant_id', $tenantId)` (or equivalent) in a global scope.

TenantResolver override (when you already have tenancy)

If your host app already has its own tenant resolver, you can override Voodflow’s resolver so it returns the correct tenant id for the current execution context.

Making fields available in the editor

Once your models are correctly scoped:

• use HasVoodflow on the model, or
• create a ModelIntegration so fields become selectable in nodes (admin-managed)

Practical examples (examples, not the purpose)

The following examples show how end-users can influence behavior via data/preferences while structural workflows remain stable.

Example: tenant-controlled notification channel

• The platform ships a structural workflow: “Order Updated”.
• The workflow loads tenant preferences (e.g. preferred_channel, whatsapp_enabled).
• An If routes to Send Mail or Send WhatsApp.

White-label value: the end-user can change preferences in your host app, but cannot accidentally remove auditing steps, break conditions, or delete required nodes.

Example: sandboxed end-user automations

You can allow end-users to build workflows with “safe” nodes (transforms, internal webhooks, model operations) while blocking sensitive ones (e.g. arbitrary outbound HTTP, raw code execution) via the denylist.

Common pitfalls

• Treating white-label as “one special workflow”: it’s usually a governance model (who can edit what) plus tenancy/scoping.
• Relying only on UI hiding: restrictions must be enforced server-side (Voodflow does this for denylisted nodes).