EPIC Goal

What are we trying to solve here?

Background/Feature Origin

Why is this important?

User Scenarios

Dependencies (internal and external)

Acceptance Criteria

Release Enablement/Demo - Provide necessary release enablement details and documents
DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
DEV - Downstream build attached to advisory: <link to errata>
QE - Test plans in Playwright: <link or reference to playwright>
QE - Automated tests merged: <link or reference to automated tests>
DOC - Downstream documentation merged: <link to meaningful PR>

Documentation Tasks:

Customer Goal

The customer's core requirement is to decouple visibility from execution for serverless workflows:

"Our goal is to configure RBAC policies so that users in a certain role can view workflow execution details, but cannot see or execute specific workflows unless explicitly permitted."

Who is your target persona?

<Role>

What stage of the user journey are you targeting?

Configuration / Security Setup (Setting up access control for the Orchestrator plugin)

Why is this content important?

This content is crucial as it directly addresses a customer pain point regarding granular security within the Orchestrator plugin. It ensures administrators can implement security policies that meet their requirements to decouple visibility (read) from execution (update/use), preventing users from seeing or running unauthorized workflows.

What is the main user goal aka job to be done?

As a Platform Administrator, I want to configure granular RBAC policies for Orchestrator workflows to decouple visibility from execution, ensuring users only interact with explicitly authorized workflows.

What high level steps does the user need to take to accomplish the goal?

1. Identify the specific [workflowId] for each workflow that needs controlled access.
2. Avoid applying the generic orchestrator.workflow or orchestrator.workflow.use permissions.
3. Grant Visibility (Read Access) using the workflow-specific permission: orchestrator.workflow.[workflowId] with the read action.
4. Grant Execution (Update Access) using the workflow-specific permission: orchestrator.workflow.use.[workflowId] with the update action.

What pain points are the user likely to encounter when accomplishing this goal?

• Confusion over the different permission levels (generic vs. named resource) and which one governs visibility vs. execution.

• Accidentally granting a generic permission, which cannot be subsequently denied/overridden for a specific workflow (due to the system’s logic: "it is not possible to grant generic... and then selectively disable it").

• Lack of a clear, documented example showing the required decoupling pattern.

Links to existing content

• Orchestrator Permissions

People:

• SME: <SME>
• QE: <QE>

Release Note: Yes/No

Documentation Outline

• The updated documentation must clearly introduce and detail the use of named resource permissions for fine-grained control:

1. Concept: Explicitly state that Orchestrator supports decoupling visibility (read) and execution (update) via specific workflow IDs.
2. Visibility Permission: Define and exemplify orchestrator.workflow.[workflowId] (read access controls viewing/listing).
3. Execution Permission: Define and exemplify orchestrator.workflow.use.[workflowId] (update access controls running/aborting).
4. Warning Box: Add a prominent note explaining that granting generic permissions (e.g., orchestrator.workflow) overrides specific denial policies and should be avoided when granular control is needed.