Workflow Templates
Without scheme composition, every scheme that needs an approval step, an escalation path, or a review gate must define those activities from scratch. Updating the pattern means editing every scheme individually - error-prone and hard to maintain.
Scheme inlining is a build-time transformation that replaces an Inline activity placeholder in a parent scheme with the complete set of activities, transitions, and parameters from a child scheme. The result is a single expanded ProcessDefinition - no separate instance, no runtime coordination, and no process boundary.
With scheme inlining, define a reusable workflow pattern once - for example, a three-step approval - mark it as inlinable, and reference it from any parent scheme. When the pattern changes, update the child scheme and all parent schemes pick up the change on the next scheme load.
What it is
Scheme inlining is like building with prefabricated parts. Instead of designing every step from scratch each time - every approval, every review gate, every escalation path - you define the pattern once as a template, then drop it into any scheme wherever you need it. When the scheme is loaded, the template is expanded in place, and the result is a single seamless process definition.
Think of a scheme as a blueprint for a process. Some steps in that blueprint repeat across many processes - for example, a three-step manager approval. Without inlining, you copy those steps into every blueprint manually. With inlining, you create the approval pattern once, mark it as a reusable template, and reference it anywhere. When the approval rules change, you update the template in one place, and every blueprint that uses it picks up the change automatically.
How it works
When a scheme is loaded and compiled, the engine finds every Inline activity placeholder, reads the referenced child scheme, and replaces the placeholder with the child's complete set of activities, transitions, and parameters. The child's start activity takes the place of the Inline activity in the parent flow, and the child's final activity is connected to whatever comes next. The expanded definition behaves exactly as if the activities were designed in a single scheme - there is no separate process instance, no child lifecycle to monitor, and no merge step.
In the visual Designer
In the Designer, an Inline activity is added through the activity context menu. It appears with a dashed border. Double-clicking it opens a properties dialog where you select the inlined scheme code from a dropdown.
The CanBeInlined flag is toggled through a toolbar button. A scheme must have at least one final activity before it can be marked as inlinable.
Parameter mappings between parent and child are configured in the inline activity properties dialog. The dialog contains Input Parameters and Output Parameters sections where you specify which values cross the boundary. Each mapping has a target parameter name, a purpose (Temporary or Persistence), and an expression. When an inlined scheme is selected, its defined parameters are loaded into the dropdown for mapping.
For developers: Use ProcessDefinitionBuilder.CreateInlineActivity(name, schemeCode) to programmatically add an inline activity. Configure parameter mappings with .SetInputParameters(...) and .SetOutputParameters(...). Mark a scheme as inlinable with builder.Inlined().
using OptimaJet.Workflow.Core.Model;using OptimaJet.Workflow.Core.Model.Builder;// Build the child scheme (the reusable pattern)var child = ProcessDefinitionBuilder.Create("StandardApproval");child.CreateActivity("Start").Initial() .Ref(out ActivityDefinition start);child.CreateActivity("ManagerApprove").Final() .Ref(out ActivityDefinition managerApprove);child.CreateCommand("Approve") .Ref(out CommandDefinition approveCmd);child.CreateTransition("approve", start, managerApprove) .TriggeredByCommand(approveCmd);child.Inlined(); // Mark as inlinable// Build the parent scheme with an inline referencevar parent = ProcessDefinitionBuilder.Create("ExpenseReport");parent.CreateInlineActivity("ApprovalStep", "StandardApproval");Why it matters
Workflow Templates deliver these outcomes:
Reusable workflow patterns - Define a standard approval, escalation, or review process once. Reference it from any parent scheme without duplicating activities, transitions, or commands.
Consistency across schemes - All parent schemes that inline the same child use the exact same process definition. When the child scheme is updated, all parents pick up the change on the next scheme load.
No runtime overhead - Inlining is a build-time transformation. The expanded definition is a single
ProcessDefinitionwith no separate process instance, no coordination, and no merge step.Parameter isolation - Input and output mappings control exactly which values cross the scheme boundary. The child scheme can define its own parameters without exposing them to every parent.
Who it is for
Evaluator (CEO, CTO, PM): Scheme inlining reduces duplication across workflow definitions. Common approval patterns are defined once and reused, making the process library easier to maintain and audit.
Developer: Use ProcessDefinitionBuilder.CreateInlineActivity(name, schemeCode) in code, or add an Inline activity in the Designer and set the SchemeCode property. Mark child schemes with CanBeInlined="true" in XML or use builder.Inlined(). Configure parameter mappings through the IInlineActivityBuilder API or directly in the Designer properties dialog.
Enterprise architect: Inlining is a build-time composition mechanism that produces a single expanded definition. It does not create independent child instances, so it avoids the lifecycle and monitoring complexity of subprocesses. The expanded definition is subject to the same scheme-level limits (activity count, transition count) as a hand-authored scheme.
When to use it
Use scheme inlining when a reusable workflow fragment must be embedded without creating a separate process instance. Inlining is the right choice when the child scheme represents a structural pattern - "Manager Approval", "Three-Level Escalation", "Document Review Gate" - that is logically part of the parent flow, not an independent process.
Inlining is also useful for enforcing consistency across schemes. Define the approval pattern once with CanBeInlined, then inline it into every scheme that needs that pattern. Updates to the inlined scheme propagate to all parents on the next scheme load - but only if the parent scheme is reloaded and rebuilt.
Do not use scheme inlining when the child should run independently with its own state lifecycle. For independent child execution with separate persistence, use subprocesses instead.
The two approaches are not mutually exclusive. A single scheme can contain both Inline activities (for build-time expansion) and subprocess calls (for runtime child instances). For example, a document review process might inline a standard approval pattern as a fixed template, then launch subprocesses for parallel department sign-offs that each track their own status.
How it compares
The table below compares scheme inlining with the alternatives of defining activities directly in each scheme and using subprocesses.
| Approach | What it requires | Result |
|---|---|---|
| Define activities directly in each scheme | Duplicate the same activities, transitions, and commands in every scheme that needs the pattern | Repetitive, inconsistent when patterns change - every scheme must be updated individually |
| Subprocess | Create a separate child scheme, spawn a child instance at runtime, merge results on completion | Independent lifecycle with persistence, monitoring, and merge logic - appropriate when the child must run autonomously |
| Workflow Engine scheme inlining | Mark the child scheme as inlinable, add an Inline activity in the parent, optionally configure parameter mappings | Build-time expansion into a single definition - no runtime overhead, no duplication, consistent across all parents |
Frequently asked questions
Does scheme inlining require a commercial license?
Yes. Scheme inlining is covered by Workflow Engine's commercial license. See the Editions page for details.
How does scheme inlining differ from a subprocess?
Scheme inlining embeds the child's activities and transitions into the parent at build time - there is no separate process instance. A subprocess spawns a child instance that runs independently and merges back on completion. Inlining is a build-time expansion; subprocess is a runtime relationship between two instances.
How do I set up parameter mapping for an inlined scheme?
Parameter mapping can be configured in two ways. In the Designer UI, open the inline activity properties dialog and use the Input Parameters and Output Parameters tables - each mapping specifies a target parameter name, purpose (Temporary or Persistence), and an expression. Expressions can reference parent parameters using the @ prefix. Programmatically, use IInlineActivityBuilder.SetInputParameters and SetOutputParameters methods with ParameterMapping objects.
Can an inlined scheme itself reference other inlinable schemes?
Yes. The inlining engine resolves the full tree of nested references. Circular references are detected and rejected.