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

SourceDescriptionSample Trigger Events
SubmissionA form submission in a kappSubmitted, Updated, Closed
UserA user record in the platformCreated, Updated, Deleted
TeamA team or group within the platformCreated, Deleted
FormThe definition of a formUpdated
Space or KappPlatform-level configurationModified

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 of a predefined parameter being used in a connector


Example 2: Dynamic Parameter Input

Here, Ruby is used inside a node parameter to dynamically pass a value from the source:

Example of Ruby code used in a parameter


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?