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 Type | Description |
---|---|
Console | Controls access to the workflow builder UI |
Categories | Organize workflows; policies here restrict visibility and interaction |
Sources | Control 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
Updated 3 days ago