Triggering Workflows with Events
Using Sources in Workflows
Sources are at the heart of event-driven workflows in the Kinetic Platform. A source represents the system activity or object that initiates a workflow, such as a form being submitted, a user being created, or a team being deleted.
When a workflow is triggered by a source event, the platform captures a payload of data from the originating system (via webhook or API), then exposes that data as predefined values that can be used throughout the workflow.
Why Sources Matter
Sources allow your workflows to:
- Automatically respond to real-time events
- Dynamically use data from the triggering object (submission, user, etc.)
- Apply logic (e.g., conditions, filters, routing) based on source values
- Seamlessly pass values into handlers, routines, or integrations
Think of sources as your workflow's context: they tell the engine what happened, where, and what data came with it.
Common Source Examples
Source | Description | Sample Trigger Events |
---|---|---|
Submission | A form submission in a kapp | Submitted, Updated, Closed |
User | A user record in the platform | Created, Updated, Deleted |
Team | A team or group within the platform | Created, Deleted |
Form | The definition of a form | Updated |
Space or Kapp | Platform-level configuration | Modified |
Each source type exposes a specific set of parameters and context values you can use inside your workflow logic.
How Source Values Are Used
The data from a source is made available in your workflow as parameter inputs and conditional expressions. These values are typically written using Embedded Ruby (ERB), which lets you insert dynamic logic into nodes, routines, or connectors.
Example:
<%= @values['Referring Id'] %>
This line returns the value of the Referring Id question from the submission that triggered the workflow.
You can also combine logic and values:
<%= @values['Referring Id'].nil? || @values['Referring Id'].empty? %>
This example checks if the Referring Id
is either null
or an empty string which is perfect for using in a connector qualification to conditionally branch the workflow.
Connector qualifications, handler parameters, and routine inputs all support ERB syntax, allowing powerful, dynamic behavior based on the triggering source.
Example 1: Conditional Connector Based on a Source Value
In the example below, the Retrieve Referring Submission node will only execute if the Referring Id
is not blank.
Example 2: Dynamic Parameter Input
Here, Ruby is used inside a node parameter to dynamically pass a value from the source:
Common Source-Based Parameters
Depending on the source type (Submission, User, etc.), you may have access to values like:
-
@values[]
– Answers from the form submission
Example:<%= @values['Phone Number'] %>
-
@submission
– Metadata about the submission (ID, timestamps)
Example:<%= @submission['id'] %>
-
@user
– Triggering user's profile data
Example:<%= @user['username'] %>
-
@space
,@kapp
,@form
– Contextual info about where the event occurred
Example:<%= @form['name'] %>
Best Practices
- Use source-specific values to route logic, populate integrations, or enrich notifications
- Always test workflows using a variety of source data to ensure your logic holds up
- Use
.nil?
or.empty?
in connector conditions to handle missing or optional values safely - Understand the limitations of each source, e.g., submissions won’t expose user details unless explicitly passed
What’s Next?
Updated 10 days ago