Subprocess

Reusable integration flow to be used within Processes.

Subprocesses are reusable integration components within Frends designed to encapsulate specific logic that can be called and executed from Processes. They enable modular development by allowing teams to build, maintain, and update shared functionality in a single location, automatically reflecting changes everywhere the Subprocess is used.

What are Subprocesses?

Subprocesses in Frends serve as building blocks for larger integrations. They are designed to be invoked by Processes rather than Triggered independently by external events. This makes them ideal for encapsulating repetitive logic, shared functionality, and reusable components that multiple Processes need.

A Subprocess starts with a Manual Trigger, which defines the input parameters it accepts. This Trigger serves as the interface through which the Subprocess receives data and configuration values needed for execution. Each Subprocess execution runs as an independent Instance with its own execution context, ensuring proper isolation and allowing for independent monitoring and debugging.

When a Subprocess is updated and saved, the changes automatically become available to all Processes that call it. This eliminates the need to update multiple Processes when shared logic changes, significantly reducing maintenance effort and ensuring consistency across your integration landscape.

Common use cases for Subprocesses include error handling and reporting, data transformation and mapping, API calls with specific authentication or throttling requirements, file operations, and any other logic that needs to be shared across multiple Processes. By extracting this functionality into Subprocesses, teams can work independently on different parts of a project while maintaining consistency and reducing duplicate code.

Usage

Creating and using Subprocesses in Frends to build modular, reusable integration components.

Creating Subprocesses

Subprocesses are created through the Subprocesses view in Frends. The Subprocess list displays all Subprocesses created in your Frends Tenant within the chosen Agent Group. All Subprocess development happens in the Development Environment before deploying them to other Agent Groups.

To create a new Subprocess, ensure your Development Agent Group is selected from the Environment and Agent Group selector, then click the Create new button to open the Subprocess Editor. The Editor interface provides a visual canvas where you can build your Subprocess flow using BPMN 2.0 notation, same as for Processes. The key characteristic of Subprocesses is that they can only use a Manual Trigger to define their starting point and input parameters, unlike Processes that can be triggered through different conditions.

Editing existing Subprocesses is straightforward. Search for the Subprocess in the list and click Edit or on the Subprocess name to launch the Editor. At least Editor role or Subprocess.Edit permission is required to create and edit Subprocesses. Without editing permission, you can only view existing Subprocesses without modifying them, and the Create new button will not be shown.

Defining Input Parameters

The Manual Trigger in a Subprocess defines the parameters that calling Processes must provide. Each parameter is configured with a Key (the parameter name), a Default value, and a Description. The Key determines how the parameter will be referenced within the Subprocess using the #trigger.data reference value.

When a Process calls a Subprocess, the input parameters are serialized before being passed to the Subprocess execution. The Subprocess then deserializes these parameters at startup, making them available through #trigger.data.ParameterName. This serialization and deserialization ensures clean data transfer between execution contexts and proper type handling across Process boundaries. You can define as many parameters as needed, and parameters can be marked as Secret to prevent their values from appearing in logs.

Building Subprocess Logic

Within the Subprocess, you build your integration logic using the same shapes and Tasks available for Processes. You can add Tasks, Scopes, loops, conditional logic, and all other capabilities of the Frends platform. The Subprocess flows from the Trigger through your defined logic and must end with a Return shape.

Variables can be created within the Subprocess using Assign Variable shapes or Code Tasks. These variables are scoped to the Subprocess execution and use the #var reference value for access throughout the flow. All internal variables remain isolated to the Subprocess and are not accessible to the calling Process.

Returning Results

Every Subprocess must end with a Return shape that specifies the value to be returned to the calling Process. The return value is serialized when the Subprocess completes, then deserialized and made available to the calling Process through the #result reference value. The return value can be any data type, from simple strings and numbers to complex objects and arrays, as long as it can be serialized.

When designing your return value, consider what information the calling Process needs. Well-defined return structures make Subprocesses easier to use and understand. The Return shape Expression field accepts any valid C# expression, allowing you to construct complex return objects or simply pass through an existing result.

Calling Subprocesses from Processes

Subprocesses are executed using the Call Subprocess shape placed within a Process. This shape is configured to specify which Subprocess to execute and what parameter values to provide. When the Process reaches a Call Subprocess shape, execution pauses while the Subprocess runs, then continues once the Subprocess completes and returns its result.

The input parameters defined in the Subprocess's Manual Trigger appear as configuration fields in the Call Subprocess shape. You can provide values directly or use expressions to dynamically calculate parameter values based on the Process's data. The Process serializes these parameter values before passing them to the Subprocess, ensuring clean data transfer regardless of complexity.

After the Subprocess completes, its return value is deserialized and becomes available through #result immediately after the Call Subprocess shape, or through #result[Subprocess Name] anywhere later in the Process. This serialization and deserialization cycle ensures that data is properly transferred between the Process and Subprocess execution contexts without shared memory or side effects.

Remote Execution

Remote execution is an advanced capability that allows Subprocesses to be executed on different Agent Groups within the same Environment. This feature enables scenarios where a target system is only accessible from within an internal network, but the calling Process needs to run in a cloud environment or public Agent Group.

When remote call is enabled for a Call Subprocess shape and the target Agent Group differs from the calling Process's Agent Group, the execution is transferred using Azure Service Bus for secure message passing. The input parameters and return values are serialized and transmitted as messages, ensuring there is no direct network connectivity requirement between the calling Agent Group and the remote Agent Group.

However, when a Subprocess is configured for remote execution but the target Agent Group and Agent match the calling Process's location, the execution occurs directly without passing through Service Bus. This optimization reduces latency for scenarios where the same Process might run on different Agent Groups in different Environments.

Remote execution is configured per Environment in the Call Subprocess shape, allowing different execution locations for Development, Test, and Production Environments. This flexibility supports scenarios where internal systems are accessed from on-premises Agents in production but simulated or accessed directly in development Environments.

Note that remote execution introduces additional latency due to message transmission and serialization overhead, and is not recommended for Processes triggered by HTTP or API calls where response time is critical. The message-based communication also means that retry handling is managed by the Service Bus infrastructure rather than within Frends itself.

Subprocess Logging and Monitoring

Each Subprocess execution is logged as its own instance in Frends, separate from the calling Process. The Subprocess Instance view shows the complete execution flow, including the values of each shape, timing information, and any error details. This independent logging provides full visibility into how the Subprocess executed and what data it processed.

The Process Instance view provides link to display related Subprocess execution through the Call Subprocess shape, allowing you to view full execution chain from the same view.

Log level settings control how much data is captured during Subprocess execution. Promoted Values can be defined to ensure specific data points are always logged, regardless of the log level setting.

Managing Variables

Subprocesses receive their input data through the Manual Trigger parameters accessible via #trigger.data. These parameters are deserialized from the calling Process at the start of execution.

Process Variables can also be used to initialize and set default values to be used within the Subprocesses. The variables are initialized right after the Subprocess is triggered and the Trigger has been executed, and before anything else in the Subprocess has been done. As such, the Process Variable values are available to use in the Subprocess right after the Trigger, but not within the Trigger.

Like the variables created using Assign Variable and code Task shapes, Process Variables provide the #var reference value for each variable created. You can of course also create additional variables using Assign Variable shapes or Code Tasks to store intermediate results and build up complex data structures.

All variables created within a Subprocess are scoped to that execution. They are not shared with the calling Process and are cleaned up when the Subprocess completes. This isolation ensures that Subprocesses remain self-contained and predictable, without side effects on the calling Process's execution context.

Any data that needs to be passed back to the calling Process must be explicitly returned through a Return shape. The returned value is serialized and transferred back to the Process, where it is deserialized and made available through the #result reference value. This explicit contract between caller and Subprocess makes the data flow clear and prevents unintended dependencies or coupling between Processes.

Configuration

The parameters and configuration options available for Subprocesses in Frends.

Name

The displayed name for the Subprocess in Frends UI. Must be unique within the Frends Tenant and can be changed as needed without breaking existing Processes that call it.

Each version of the Subprocess receives a unique ID used for backend references. This allows Processes that call the Subprocess to continue functioning even when the Subprocess is renamed, as the references are based on the internal ID rather than the display name.

Version

Version number following semantic versioning scheme. The build number automatically increments each time the Subprocess is changed and saved. Major and Minor version numbers can be changed manually by the developer when introducing significant changes to the Subprocess interface or behavior.

Version tracking helps teams understand when changes were made and coordinate updates across development and production Environments. The version history is preserved and accessible through the changelog feature.

Last modified

Shows when and who edited the Subprocess most recently. This information helps track changes and coordinate development efforts across teams, particularly when multiple developers are working on related integration components.

Description

A short description field providing information about the Subprocess in the Subprocess list view. Content entered here appears as a subtitle in the list, helping developers quickly understand the purpose and functionality of each Subprocess without opening the Editor.

Links included in the description are functional, allowing you to reference detailed documentation stored elsewhere such as Confluence pages or external systems.

Documentation

Frends provides a built-in documentation editor for each Subprocess. Markdown formatting is supported, enabling rich documentation with headers, lists, code samples, and formatting. The Frends AI Assistant can generate documentation automatically based on the Subprocess logic.

Well-documented Subprocesses are easier to reuse across teams and projects. Documentation should clearly explain the Subprocess's purpose, the meaning of each input parameter, the expected return value structure, and any error conditions or special behavior.

Target framework

Each Subprocess is compiled using a specific .NET version that Frends supports. The target framework determines which .NET features and libraries are available within the Subprocess.

.NET 8.0 is the current default target framework, providing access to the latest features and performance improvements. .NET Framework 4.7.1 is available for legacy Frends Environments that do not yet support .NET 8.0 or use functionality no longer available in newer versions. .NET Standard 2.0 can be used for migration purposes but is not recommended for new development as it does not receive new features.

Disable caller cancellation

When enabled, the Subprocess execution continues even if the calling Process or Trigger cancels the request. This option ensures that operations which must not be interrupted once started will complete regardless of what happens in the calling Process.

For example, if an HTTP request to Frends times out or is cancelled, normally any executing Subprocess would be stopped as well. Enabling this option ensures the Subprocess completes its work, which is important for operations like financial transactions or critical data updates that must complete atomically.

Subprocess Actions

Additional actions and utilities available for working with Subprocesses.

Import BPMN

The Subprocess Editor supports importing BPMN 2.0 diagrams using the Import BPMN function. BPMN diagrams can be imported in text, xml, or bpmn formats, allowing you to bring in process diagrams created in other tools.

Frends does not support the full range of BPMN 2.0 shapes, and any non-supported shapes will either not be imported or will be replaced by simpler forms that Frends supports. The import function is useful for initial process modeling but may require adjustments to the imported diagram.

Note that exporting and importing complete Frends Subprocesses uses a proprietary JSON format rather than BPMN files. The JSON format includes both the BPMN diagram and all associated configuration, code, and parameters.

Export BPMN XML

Enables exporting the BPMN diagram for the Subprocess in XML format. Only the BPMN diagram structure is exported without any Frends-specific configuration or functionality. This feature is intended for including process diagrams in documentation or presentations.

Save as picture

Exports the Subprocess diagram as an SVG file. The SVG format is scalable and suitable for documentation, presentations, and technical specifications where high-quality process visualization is needed.

Show changelog

Displays the version history for the Subprocess, including who made changes, when they were made, and any comments added during the save process. The changelog provides an audit trail of all modifications to the Subprocess over time.

Diff

Comparison tool for viewing differences between versions of the Subprocess. The diff tool highlights changes, additions, and deletions between selected versions, making it easy to understand what has changed and review the impact of modifications before deploying to production.

Reference values

Subprocesses provide several reference value objects for accessing data and metadata during execution.

#var

Representing a variable in Frends Processes, #var reference values can be created as Process Variables from the Subprocess's general parameters, or during Subprocess flow using Assign Variable or Code Task shapes with Assign variable parameter enabled.

All methods to create variables in Frends Subprocesses require defining a name for the variable. The variable can then be used as #var.MyVariable, if MyVariable is set as the variable's name.

Variables are scoped to the Subprocess execution. They persist throughout the Subprocess flow but are not accessible to the calling Process. Variables from the calling Process are also not accessible within the Subprocess unless provided as input parameters through the Trigger.

Any data needed by the caller must be returned through a Return shape, where it will be serialized and transferred back to the Process.

#trigger

The Trigger reference value provides access to the Manual Trigger and its parameters. For Subprocesses, the most important reference is #trigger.data, which contains all input parameters defined in the Manual Trigger.

#trigger.data

Object containing the input parameters passed to the Subprocess. Any parameter defined in the Manual Trigger is accessible as #trigger.data.ParameterName, where ParameterName matches the Key defined for the parameter.

Parameters are serialized when passed from the calling Process and deserialized at the start of Subprocess execution. This ensures clean data transfer and proper type handling across execution contexts.

#process

Process reference values contain information about the specific Subprocess execution as well as metadata about the Subprocess itself. These values are set when the Subprocess Instance is created.

#process.agent (String)

Name of the Frends Agent that executed the Subprocess. For remote Subprocess calls, this reflects the Agent in the remote Agent Group where the Subprocess actually ran.

#process.agentGroup (String)

Name of the Agent Group where the Subprocess was executed. For remote calls, this shows the target Agent Group rather than the calling Process's Agent Group.

#process.cancellationToken (System.Threading.CancellationToken)

Enables cancellation of longer operations within the Subprocess, such as loops or long-running Tasks. The cancellation token allows graceful termination of Subprocess execution when needed.

Without using the cancellation token in loops and long-running operations, some executions cannot be terminated until they complete naturally. Checking the cancellation token periodically allows responsive termination.

#process.environment (String)

Name of the Environment where the Subprocess was executed, such as Development, Test, or Production.

#process.executionid (String)

Unique ID for the Subprocess Instance. This can be used to construct a direct URL to view the Subprocess execution logs or to correlate log entries across systems.

#process.id (String)

Unique ID for the Subprocess, specific to the version that was executed. This ID remains constant for a given version of the Subprocess across all executions.

#process.name (String)

Name of the Subprocess that was executed.

#process.uri (String)

URI for the Subprocess. Contains the Process type (Subprocess), its unique identifier, and the build version. This URI can be used for programmatic references to the Subprocess.

#process.version (String)

Version of the Subprocess that was executed, following the semantic versioning format.

Examples

Learn more about Subprocesses from the following guides and docs:

• Call Subprocess

• Creating a Subprocess