Transitions and Permissions
Transitions and Permissions defines how a Workflow Engine Process Instance moves between Activities and how the application decides who can request that movement. Timers make time-based Transitions eligible for consideration, Work Calendars calculate selected intervals in working time, and Conditions select a valid path. Actors, Rules, and Restrictions filter the Commands available to an Identity. Workflow Runtime can evaluate the same Restrictions again when a Command is executed.
Transitions and triggers
A Transition connects two Activities. Its Trigger determines when Workflow Runtime considers it. A Command or Timer can activate a Transition, while Workflow Runtime evaluates an Automatic Transition without an external Trigger.
Transition: A directed connection from a source Activity to a target Activity. A Transition can define a Trigger, Conditions, and Restrictions.
Fork Transition: A Transition with IsFork enabled that starts or finishes a Subprocess branch used by Parallel Processes. A starting Fork Transition creates a child Process Instance; a finishing Fork Transition finalizes the child and continues its Parent Process.
Trigger: The mechanism that activates a Transition candidate. Command, Timer, and automatic trigger are common Trigger types. A Trigger activates a candidate; it does not decide permission.
Command: A named external Trigger that asks Workflow Runtime to execute an eligible Transition from the current Activity. A Command can carry input Parameters. The application supplies the workflow participant identity that initiates Command execution and, when using impersonation, the workflow participant identity on whose behalf the Command is executed. Identities lists the workflow participant identities that can execute the returned Command. A Command does not contain the business logic of an Action.
Timer: A time-based Trigger that causes Workflow Runtime to consider a Transition when its calculated due time is reached. TimerType determines how that due time is calculated: Interval, Time, Date, DateAndTime, or Expression. A Work Calendar affects only an Interval value written in working-time units; it does not change other interval values or any other Timer type.
Automatic Transition: A Transition activated by runtime evaluation instead of an external Command or a Timer. An Automatic Transition can still have Conditions.
Work Calendar: A definition of working and non-working time used to calculate Timer delays in working-time units. It affects only Interval Timers whose values use units such as working days or working hours; other interval values and the other Timer types do not use its rules. In code, ICalendar is the public contract, Calendar is the built-in implementation, Calendars holds registered calendars, and CalendarName selects one for a Process Instance or Scheme; the runtime default can be used when neither selects one. Working Calendar is an explanatory name for the same concept, but Work Calendar is the feature name.
Conditions and actions
Conditions determine whether an eligible Transition can run, while Actions implement behavior during workflow execution. Neither concept determines who is allowed to request a Transition.
Condition: A Boolean flow guard defined on a Transition in a Scheme and evaluated while Workflow Runtime selects an eligible Transition. An Action Condition (ConditionType.Action) stores a reference to named Condition logic implemented by a Code Action or a registered IWorkflowActionProvider. An Expression Condition (ConditionType.Expression) stores its C# expression directly in the Transition's Condition definition. During Pre-Execution, ResultOnPreExecution can provide a fixed result for the Condition. A Condition controls which path can run; it does not determine whether a user has permission.
Always Condition: A Condition represented by ConditionType.Always. During normal execution, it passes without running Action or Expression Condition logic once its Transition is a candidate. Always does not make the Transition automatic by itself.
Otherwise Condition: A fallback Condition represented by ConditionType.Otherwise. Workflow Runtime considers it only after selecting no Transition with an Always Condition and finding no passing Action or Expression Condition; the order is Always, Action or Expression, then Otherwise. Otherwise is a flow fallback, not a permission Rule.
Action: Named business logic referenced by an Activity's Implementation during normal execution or by PreExecutionImplementation during Pre-Execution (Simulation). The host can supply Actions through the exact interface IWorkflowActionProvider, sometimes called an Action Provider. Workflow Runtime invokes an Action while executing or simulating a workflow; an Action is not a Command submitted by an external caller.
Identities and permissions
The host application authenticates a caller and supplies Identity values to Workflow Engine. When the application asks which Commands are available, Workflow Runtime evaluates Actors, Rules, and Restrictions for those identities. It evaluates the Restrictions again during Command execution only when the caller requests that check.
Authentication: The host application's process for establishing who the caller is. Workflow Engine consumes the resulting Identity but does not replace ASP.NET Core or another host authentication system.
Authorization: A decision about what an authenticated Identity may do. Workflow Transition authorization uses Actors, Rules, and Restrictions to determine which Commands are available and, when requested, to check the Actor Identity again before execution. Authenticating the caller does not automatically request this execution-time check. Workflow Engine HTTP API authorization separately controls access to HTTP operations and tenant data. These scopes share a general security purpose but are not one mechanism.
Workflow Participant: A person, system, or other application-defined party that takes part in a workflow. The host application represents it to Workflow Engine with an Identity; Workflow Participant is a conceptual term, not a separate runtime type.
Identity: An application-defined identifier for a Workflow Participant, passed to Workflow Engine for permission checks and audit data. Workflow Engine does not require Identity to be a particular user-object type.
Rule: A named permission check that determines whether an Identity matches an authorization requirement. A Rule controls access and is not a flow Condition. The host supplies Rule checks and matching identities through the exact extension interface IWorkflowRuleProvider, commonly described as a Rule Provider.
Actor: A Scheme declaration that connects a Restriction to a Rule name and optional value. An Actor describes how Workflow Engine resolves eligible identities; it is not the host application's user object.
Predefined Actor: An Actor that the application makes available to selected Schemes, or to all Schemes, without saving a separate copy in each Scheme. Workflow Runtime includes it when it reads a matching Scheme, and Workflow Designer includes it in a new empty Scheme. Restrictions use it like any other Actor. The application still decides which Identities match it, so it is not a hard-coded list of users. In code, Basic Plugin registers one name with WithActor or several with WithActors.
Restriction: An access setting on a Transition that says who may use it. It refers to an Actor and either lets matched identities use the Transition (Allow) or blocks them (Restrict). Workflow Runtime applies Restrictions when it lists available Commands. During Command execution, it checks them only if the application explicitly requests the check. Workflow Engine HTTP API follows the same rule.
Impersonation: A workflow operation in which one Workflow Participant acts on behalf of another. Workflow Engine records both Identities: the Executor Identity identifies the Workflow Participant that submits the operation, while the Actor Identity identifies the Workflow Participant on whose behalf it runs. If the application requests a Restriction check, Workflow Runtime checks the Actor Identity.
Actor Identity: The Identity of the Workflow Participant on whose behalf a workflow operation runs. It can differ from Executor Identity during Impersonation. In code, the corresponding Process Instance property is ImpersonatedIdentityId.
Executor Identity: The Identity of the Workflow Participant that submits a workflow operation. It normally matches Actor Identity but can differ during Impersonation. In code, the corresponding Process Instance property is IdentityId.
Pluggable Security: The Workflow Engine capability for connecting application-defined Workflow Participant Identities and Rule logic to workflow authorization. Pluggable Security is not a standalone authentication product.
See also
These pages explain the model elements and security behavior behind the terms.
- Transition explains connections between Activities.
- Command explains external workflow Triggers.
- Pluggable Security describes authorization integration.
- Glossary overview links to the other terminology subjects.
Frequently asked questions
What is the difference between a Command and an Action?
A Command is an external Trigger that requests an eligible Transition. An Action is business logic executed inside workflow execution.
What is the difference between a Condition and a Rule?
A Condition decides whether a workflow path is eligible. A Rule determines whether an Identity matches an authorization requirement used by an Actor and Restriction.
Is a Workflow Participant the same as an application user?
Not necessarily. A Workflow Participant can be a person, system, or other application-defined party. For a user, the host application maps its user account to an Identity and passes that Identity to Workflow Engine. A system participant can be represented by an Identity without a user account.
Does Workflow Engine authenticate application users?
No. Users sign in through your application, not through Workflow Engine. The application passes their Identity to Workflow Engine, which can use it to determine which Commands are available and record who acted in the workflow.