Workflow Template
Defines a reusable unit that represents a complete custom process, designed by a user to follow a sequenced logic from start to end. Each Workflow Template is designed for a specific Target Object which means it can be applied to different records of that Target Object.
A Workflow Template does not represent an actual running Workflow.
The following elements compose a Workflow Template: Nodes (Steps) and Connections.
Connection
Defines the branch or routing logic that connects two nodes.
Nodes/ Steps
Elements or building blocks that can be part of a workflow. Each has a specific role in defining the process, and comes with its own configuration options. Type of nodes are:
Starting Rule | Rules | Tasks | Delays | Automatic Process | Nested Workflow | Completion Rule |
The Starting Rule is a mandatory node that initiates a workflow. It listens for a trigger event (such as a scheduled time or system event), evaluates conditions when the trigger fires, and creates a new workflow record if the conditions are met. It can have multiple routes based on different conditions and triggers the next step in the fired route | They are decision points that automatically evaluate field values, conditions, or events to determine the next workflow path. Unlike tasks, which depend on user actions, rules enable conditional routing based on real-time data and system state. | Tasks are a reusable unit of work with a specific configuration that must be performed by a user or group of users. This allows a running process to move forward once completed. | A delay allows to pause a workflow execution for a specified period or until a specific condition is met. It allows workflows to wait before continuing to the next step. | An automatic process in Neostella that is configured to automatically run without human intervention. | A nested workflow that represents a small sub-process within your current workflow. | The completion rule allows to map all the possible finish points in the workflow, then configure it when that workflow will be considered closed by the platform. It is useful when nested workflows are used to map and provide a clearly understanding of the possible outcomes of the nested workflow.
|
A Task Template does not represent an actual Task record, until it is generated by a Workflow record.
Object Record
Represents the specific data entity or record type that a Workflow monitors or acts upon. This is a specific, concrete record of a given Object (data entity type) within the system. It represents a unique, identifiable data item that contains actual values in its fields. For example: If the Object is Project, then an Object record might be a particular project record such as “Mass Tort Case- John Smith 1023”, which contains particular data.
Path
Defines one of the possible output points a node can have, to allow connections between the workflow nodes.
Resolution Code
Are customizable descriptors used by final task resolvers to categorize how tasks are completed. They define the possible outcomes when resolving a task (for example:, Approved, Rejected, Needs Review) and also can define the subsequent workflow branch that is followed based on the selected code.
Target Object
One of the system-default, predefined Objects that a Workflow Template can be associated with or point to.
Task Record
An actionable unit of work created during the execution of a Workflow Record. It represents a task assigned to a user or system, with a defined purpose and outcome. Each Task record:
- is derived from a Task Template.
- is linked to a Workflow record and its related Object.
- will begin as a potential task.
- becomes active only when its condition is met.
- tracks status (pending, in progress, completed).
- may trigger other task records or workflows based on resolution or outcome.
Workflow Record
A runtime item created when the configured Triggers in the Starting Rule in a Workflow are satisfied by a specific Object. It represents the execution of the workflow’s logic, configurations and steps for that specific Object.
Outcome Code
Customizable descriptors used by to categorize how:
- Tasks are completed.
- Workflows are closed.
- Tasks are snoozed.
They define the possible outcomes to categorize when:
- Resolving a Task: When resolving a task, the selected Outcome Code categorizes the result and can also determine the subsequent workflow branch that should be followed based on that selection.
- Workflow Closure: When a workflow is closed, an Outcome Code is assigned to represent how the workflow ended. This Outcome Code not only categorizes the closure, but also defines the subsequent workflow branch that should be followed based on the result. This is especially important for nested workflows, where the Outcome Code allows the parent workflow to understand that the nested workflow has been completed, identify how it ended, and determine the appropriate next step based on that result.
- Snoozing a Task: When snoozing a task (for example: Client cannot be contacted, Waiting for response, Requires additional activities), the Outcome Code categorizes the reason for the delay and helps track why the task was paused.