Processes
A Process is a collection of Steps that are strung together to achieve a business goal.
Similar to programming language functions, Processes receive inputs, run some business logic, and (optionally) return
some output.
Processes can run across multiple services, with durations ranging from milliseconds to years. By design, Processes are resilient to failure and can gracefully resume work after interruptions. With Unmeshed, Process Authors typically don't need to worry about orchestrating steps or having to restore execution after a failure. This complexity is almost removed in its entirety, which allows you to focus on adding value to your business.
There are many different ways to use Processes. Here are some examples:
| Example Use-Case | Example Process | Input | Output |
|---|---|---|---|
| Aggregate APIs | Calls the /orders and /customers APIs to generate an invoice | order ID | PDF invoice |
| Onboard new customer | Sends a welcome email, checks on progress in 2 weeks and sends tailored follow-ups | customer email | Was onboarding successful? |
| Dynamic intent | Uses LLMs to determine which process to trigger | free-form text | The output of the triggered process |
| Approval workflow | Sends an approval request to the person's manager via Slack | expense item, employee ID | Approval result |
Video Overview : What is a Process in Unmeshed?
Process Definition
A process is defined using the process definition data model. Refer to Process Definition for details on what the process definition looks like.
Process Context
Every Process has a ProcessContext associated with it. It contains high-level information about the executed process,
such as its id, received inputs, execution status, and output. It is accessible to every step as part of the
process execution. Some of the most commonly used fields are listed below.
The full list of fields are:
| Field | Description |
|---|---|
id | The system-generated unique identifier for the process. |
correlationId | User-provided correlation ID (optional). |
requestId | User-provided request ID (optional). |
status | The current execution status of the process, refer to Process Status |
start | Epoch timestamp for when the process started. |
end | Epoch timestamp for when the process completed. |
input | A key-value pair representing the inputs provided to the process. |
output | A key-value pair representing the output of the last step of the process. |
triggerType | The type of trigger that initiated the process, refer to Trigger Type Details. |
authClaims | A key-value pair representing the authentication claims related to the process. |
createdBy | The user or system that created the process. |
Outputs and inputs
As previously described, a Process may have inputs and output. Inputs are used as parameters for a specific execution
of the process. For example, for a process that fetches customer information from an external API, you might want to
pass the customerId as input. Using the same example, we might expect the output to be a json representation of the
customer or perhaps a link to a report stored on AWS S3.
Input and output objects are json objects, meaning that every entry requires a key and a value. For example, if you
wanted to start a process to query a specific order ID, you could use the following input:
"queryId": 12345
Refer to this page for details on how to pass variables or context between steps and how to use secrets and variables.
Triggering processes
Processes can be triggered in multiple ways:
- Using the executions API, API Mappings or Webhooks attached to API mappings
- Using predefined Schedules
- Manually using the UI (typically for building / testing)