Grant workflow access correctly
26R1 reference · Documentation-based tutorial draft · Not executed in IFS
Three different access questions
Section titled “Three different access questions”Ask who may edit the workflow, who may invoke it, and which business activities it may perform. Giving someone access to the designer is not the same as authorizing an end-user operation.
The workflow acts on behalf of the initiating user. Do not design an impersonation step or assume administrator access will apply to everyone.
Understand the grant types
Section titled “Understand the grant types”| Workflow grant | What it authorizes |
|---|---|
| External | Direct access through the workflow REST endpoint |
| Internal | The reviewed business activities performed through the workflow |
| Full | Both External and Internal access |
External access alone does not authorize every API operation inside the workflow. Internal grants let an administrator authorize the workflow’s reviewed activities without granting each activity directly to the user.
If all activities already have direct projection grants, the workflow’s Internal grant is not the mechanism used to supply those permissions.
Review and grant
Section titled “Review and grant”- Identify the real business role and required trigger.
- Add the workflow to the appropriate custom permission set.
- Inspect the Available Projections and activities for that workflow.
- Select the smallest grant type that meets the requirement.
- Assign the permission set through the approved role process.
- Test with a business user and a denied user.
Workflow grants are not inherited through nested functional or end-user-role permission sets according to the referenced release guidance. Verify effective access rather than assuming nesting carries them.
Event-triggered processing also needs the projection access used to retrieve the event logical unit’s metadata. A workflow can fail before its first modeled task if that access is missing.
Redeployment can invalidate access
Section titled “Redeployment can invalidate access”Adding or changing activities can invalidate an Internal or Full grant and require another review. Include grant state and projection-review state in every release check. A successful deployment is not proof that the previous users can execute it.
Do not fix an invalidated grant by granting every workflow or every projection. Review what changed and authorize those activities intentionally.
Why Troubleshoot differs
Section titled “Why Troubleshoot differs”Workflow-level grants apply to normal execution, not Troubleshoot, where a diagram can be modified. Inspection therefore needs direct API grants. A troubleshooting FndProjectionGrant.SRV_NOT_ACCESS error can occur even when the deployed, reviewed workflow works for that role.
Conversely, an administrator successfully inspecting a workflow proves little about end-user access. Test both paths.
Acceptance evidence: author access, allowed invocation, denied invocation, direct API access where required for inspection, and behavior after a deployment that changes activities.