Securing Workflow Access

Workflow Security

While form and submission policies control what users can see and do, Workflow Security governs access to the automation layer of the Kinetic Platform, specifically workflow categories, sources, and API-triggered tasks.

This ensures that background actions like data pushes, API calls, and integration events are only run by trusted users and systems.


Where Workflow Security Applies

Workflow Security is managed under:

Space Console → Settings → Workflow → Policy Rules

There are three types of workflow elements you can secure:

Element TypeDescription
ConsoleControls access to the workflow builder UI
CategoriesOrganize workflows; policies here restrict visibility and interaction
SourcesControl access to inbound API requests and task triggers

Each of these supports one or more security policies to determine who can access them and under what conditions.

Learn More



Key Difference: Ruby Rules

Unlike form and submission policies, workflow policies are written in Ruby, not JavaScript.

This is because they run inside the task engine, which uses a Ruby-based ruleset for evaluating logic.

Example Workflow Security Rules

Restrict to a specific team:

@identity.is_member_of('Team::Admins')
 

Allow only local dev traffic:

['127.0.0.1'].include?(@request.remote_addr)

Check for multiple conditions (team + IP)

@identity.is_member_of('Team::Approvers') &&
  ['192.168.1.100'].include?(@request.remote_addr)


Securing Workflow Sources

Sources represent external systems or services that trigger workflows via API calls.

You can:

  • Apply security policies to individual sources
  • Limit access to internal tools or service accounts
  • Use identity and IP-based checks to restrict inbound automation

Find this under Space > Settings > Workflow > Sources and select the source you want to secure.


Best Practices

  • Lock down production sources to only allow expected integrations
  • Use team-based rules for access to sensitive or high-impact categories
  • Test with known IPs to confirm behavior before applying broadly
  • Name your rules clearly for easy maintenance
  • Document custom Ruby rules if using advanced logic

Tip

If a workflow or source isn’t behaving as expected, check for any denied access from applied security policies in the platform logs or workflow run history.


🔗 Related Topics