Triggers

What is a trigger?

Triggers initiate workflows in Rewst. Every workflow must have a trigger to define when and how it starts. Essentially, triggers put the automate in automation. Choosing the right trigger ensures that your workflows execute at the right time, with the right data, to drive efficiency and consistency in your operations.

A trigger is also used on any form input that requires a workflow. If a form uses the Dynamic button, then you must also create a trigger on the workflow associated with that form.

For more on how to see which triggers appear on a specific workflow, view our documentation here.

View all triggers

Navigate to Automations > Triggers in the left side menu of Rewst to view the total triggers page, which contains a sortable list of all triggers in your Rewst instance, organized by tabs labeled with automation type. This includes triggers from your custom-built workflows and from unpacked Crates. Click on any of the column headers to sort the list by that criteria. Use the Tags drop-down selector to filter the list by specific tags.

Toggle any trigger to enabled or disabled in the Status column. Once toggled on, the slider will turn green, and a green checkmark will appear to the right to let you know that the enablement is complete.

We're currently working on a feature limitation that prevents the last activity display for Always Pass and Interval triggers. Instead of listing the last activity, the trigger will show that it has never been activated. For these particular trigger types, confirm the last time the trigger was activated directly in the trigger rather than in the triggers page.

Three trigger modes in Rewst

Rewst launched the new Workflow Builder in May of 2026. Prior to that product change, the term completion handler was used to refer to the interlinking of workflows. If you're a seasoned Rewst user, note that completion handlers are now achieved via inbound and outbound triggers.

There are three trigger modes in Rewst. All are selected when creating your trigger in the trigger settings of the right side menu. Trigger modes can't be edited after a trigger is created. Click each type below to expand and learn about different modes.

Integration mode: Workflow triggered by an integration

his is the default choice for standard events within the Rewst platform. The workflow waits for specified events to happen in your partner tools, if those partner tools are integrated with Rewst. Examples include ticket updates in your PSA, or user creation alerts. When you choose integration mode, the Trigger Type drop-down selector appears with a complete list populated to include all of your Rewst integrations.

Inbound mode: Workflow triggered by another workflow's completion

This enables the workflow to start when another workflow completes, pulling in the data from each run. The workflow you're currently setting up is the first, enabling workflow in this scenario. Examples include alerting for failed workflow executions, like kicking off the trigger based on a failed status. These workflows have a context variable that can be used to reference previous contexts from the workflow that was completed. Select one or more status conditions that will trigger the target workflow

Contexts from the previously run workflow can be accessed with the COMPLETED_WORKFLOW variable. You can access most info via the context including ORG and CTX such as:

1. {{ COMPLETED_WORKFLOW.ORG.VARIABLES.cw_manage_company_id }}

2. {{ COMPLETED_WORKFLOW.CTX.user.username }}

Inbound and outbound triggers will always run in the context of the parent organization. If you are taking actions on a suborganization in the workflow, then you must use the run-as-organization functionality and overrides set at the trigger level.

The organization ID that was used in the previous workflow context can be referenced with the following Jinja:

{{ COMPLETED_WORKFLOW.ORG.ATTRIBUTES.id }}

Test inbound triggers

Inbound trigger data is hard to fake for testing because it's represented as COMPLETED_WORKFLOW. instead of CTX.COMPLETED_WORKFLOW. Rather than running an entire workflow multiple times to test just this one element, create a noop action that sets the test data, and use it to trigger your inbound trigger.

In the noop, set all of the variables that will be used in your inbound trigger in the On Success transition as data aliases.

It’s important that the names of the data aliases you create in the On Success transition of the noop match both:

• the names of the variables that will be used in your inbound trigger

• the names of the variables that will be used in the live parent workflow that your inbound trigger is triggered by

Add static values that represent a good test case for ensuring that your inbound trigger functions the way you expect.

Example: Test inbound triggers

In the example below, we’ve created a workflow with a single noop. In the On Success transition, we’ve added several data aliases that represent user data that could be used to test a completion handler, which could be used after a user is onboarded or offboarded.

The noop action, its On Success transition, and the corresponding data aliases

Once you’ve created the noop and added the correct data, attach this workflow to your other workflow's inbound trigger as another parent workflow that will trigger the the inbound trigger. This will enable testing. If you need to run your test workflow for organizations other than your parent MSP organization, add a trigger to the workflow which will allow you to select which organization the test workflow runs for.

Outbound mode: Workflow's completing triggers another workflow

This enables another workflow to start when your workflow completes, pulling in the data from each run. The workflow you're currently setting up is the second, completing workflow in this scenario. These workflows have a context variable that can be used to reference previous contexts from the workflow that was completed. Select one or more status conditions that will trigger the target workflow

Contexts from the previously run workflow can be accessed with the COMPLETED_WORKFLOW variable. You can access most info via the context including ORG and CTX such as:

1. {{ COMPLETED_WORKFLOW.ORG.VARIABLES.cw_manage_company_id }}

2. {{ COMPLETED_WORKFLOW.CTX.user.username }}

Inbound and outbound triggers will always run in the context of the parent organization. If you are taking actions on a suborganization in the workflow, then you must use the run-as-organization functionality and overrides set at the trigger level.

The organization ID that was used in the previous workflow context can be referenced with the following Jinja:

{{ COMPLETED_WORKFLOW.ORG.ATTRIBUTES.id }}

Inbound and outbound workflow triggering should be linear, never circular. Don't set two workflows to continually run when the other completes. This will cause the workflows to trigger each other in an infinite loop.

Create a trigger

Depending on your workflow, you may have one trigger or multiple triggers— for example, a webhook trigger and a trigger that runs when a ticket gets saved in your PSA. In either case, to begin:

1. Click to open the library.

2. Click the Flow Control tab.

3. Drag the yellow Triggers bar onto your Workflow Builder Canvas.

4. Click on the bar to open trigger settings in the right side menu. Note that if you have one trigger or many triggers, all will show up in this right side menu in a list, which is always accessible by clicking the yellow bar. The number of total triggers will appear in a counter box in the far right of the dragged yellow bar.

Note the Flow Control tab on the left, and the trigger settings on the right.

1. Click + Add Trigger.

2. Fill out the Trigger Settings menu as follows:

   1. Enter a descriptive name into the Trigger Name field.

   2. Toggle the trigger to Enabled to use it in the workflow.

   3. Use the Trigger Mode drop-down selector to choose the mode for your trigger:

      1. Integration: The workflow is triggered by an integration with Rewst. If this is selected, choose a Trigger Type from the drop-down selector. Read more about trigger types in the later sections of this document.

      2. Inbound: The workflow's start is triggered by another workflow.

      3. Outbound: The workflow's completing triggers another workflow.

   4. Fill out the fields that appear depending on your trigger mode selection. For more on trigger modes and their required fields, see the trigger mode section of this document.

3. Optional: Click the Overrides tab and add integration overrides.

4. Optional: Click the Run For tab and add or tags.

5. Click Save Trigger.

6. Follow the process again to add additional triggers.

Trigger criteria

When you're comfortable with the basics of triggers, learn more about trigger criteria here. It's a separate submenu tab the trigger menu, and has its own documentation page. The below table outlines the fields in the trigger criteria configuration menu.

Item	Description
Name	Whatever you would like to name your trigger, with a descriptive word or phrase for what it does.
Enabled	Toggle this on or off.
Organizations	Select all the organization that exist within Rewst that may need to use this workflow. If you add a new client, they will have to be added in that workflow trigger.
Integration Override	To give the workflow access to integrations and credentials owned by the parent organization, that default behavior must be explicitly overridden. In the above example image, the trigger allows your clients to use your PSA, RRM and licensing integration. See more about integration overrrides in the next section of this document.
Trigger Type	There are a number of types to choose from, such as a webhook, form submission, ticket saved, M365 alerts. See Core triggers for more information on common trigger types.
Form	If your trigger type is a form submission, you would select the form that links to the workflow.

What are integration overrides

Integration overrides allow selection between multiple versions of the same integration at both the trigger and action levels, enabling granular control over workflow execution. When a workflow is triggered by and running within the context of a child organization, by default it only has access to the org's own integrations and configurations. To give the workflow access to integrations and credentials owned by the parent organization, that default behavior must be explicitly overridden. Rewst recommends adding more integration overrides rather than fewer.

Choose the integration for which to apply configuration overrides to by clicking +Add Integration Override and selecting from the list.

1. Click next to integration overrides.

2. Choose your desired integration or integrations from the drop-down selector that appears. This will populate the options for that integration below the selector. Each selected integration will have its own accordion menu added to the trigger configuration page.

   1. Configuration Selection Mode options

      1. Use Default - The default configuration for the workflow owner will be used

      2. Use Selected Config - Select a specific integration configuration to use: choosing this option reveals a new Integration Configuration drop-down selector where you'll choose an existing configuration

      3. Use Name Search - Search the workflow owner's integration configurations by name: choosing this option reveals a new Configuration Name field where you'll enter the name

   2. Configuration Fallback Mode - The behavior to be used if the selected configuration is not found, available for all Configuration Selection Mode options excluding Use Default

      1. Use Org Mapping - Use the organization mapping defined in the integration settings page to select the configuration to use

      2. Fail Workflow - If the matching configuration is not found, the workflow will fail with an error

Add an integration override

1. Click the Overrides tab.

2. Choose your desired integration from the selector that appears. You may select multiple integrations, but must choose one at a time. Click + Add Integration Override each time to add another integration, and Edit Integration Override to return to the list for additional selections. This will populate the options for that integration below the selector. Each selected integration will have its own menu added to the overrides list.

1. For each integration override, choose from the following settings:

   1. Use Default - The default configuration for the workflow owner will be used

   2. Use Selected Config - Select a specific integration configuration to use: choosing this option reveals a new Integration Configuration drop-down selector where you'll choose an existing configuration

   3. Use Name Search - Search the workflow owner's integration configurations by name: choosing this option reveals a new Configuration Name field where you'll enter the name

   4. Configuration Fallback Mode, available for Use Selected Config and Use Name Search only - The behavior to be used if the selected configuration is not found, available for all Configuration Selection Mode options excluding Use Default

      1. Use Default - If the matching configuration is not found, the default configuration for the workflow owner will be used

      2. Fail Workflow - If the matching configuration is not found, the workflow will fail with an error

2. Click Submit.

Note that when you unpack a Crate, it will automatically look at your installed integrations to decide which integration overrides to apply to your particular unpack. If you add additional integrations or change integrations after a Crate has been unpacked, and want that integration to be recognized and used with integration overrides for the Crate's workflow, you'll need to go to the trigger for that workflow and manually add the new integration to the integration overrides field.

Integration override on an action

While integration overrides mainly live on and apply to triggers, you can also add them to actions under the Advanced tab of their right side configuration menu. The main use case for an action-based integration override is when you use multi-instance integration in Rewst.

The process and selections for this integration override are the same as for those set on a trigger.

If you've set integration overrides on both the trigger and an action in a workflow, the action override takes precedence over the trigger override and will cancel it out.

Activate trigger to run for

This submenu controls which organizations a workflow trigger is enabled for. When a triggered, it determines which organizations the workflow can execute in the context of. Each trigger on a workflow has its own Activate Trigger To Run For settings. They aren't shared between multiple triggers on the same workflow.

1. Selected Organization toggle

   1. Toggled on by default, this enables the trigger for the organization that owns the workflow, usually the parent organization

   2. Toggle off if you don't want the workflow to run for the owning organization

2. Organizations drop-down selector

   1. Manually select specific organizations

   2. Choose individual child organizations that should have this trigger active

3. All Current and Future Managed Organizations toggle

   1. Toggle on to automatically enable the trigger for:

      1. All currently existing child organizations

      2. Any new organizations added in the future - automatically included

4. Click the Run For tab.

5. Choose your settings:

   1. Selected Organization toggle

      1. Toggled on by default, this enables the trigger for the organization that owns the workflow, usually the parent organization

      2. Toggle off if you don't want the workflow to run for the owning organization

   2. All Current and Future Managed Organizations toggle

      1. Toggle on to automatically enable the trigger for:

      2. All currently existing child organizations

      3. Any new organizations added in the future - automatically included

   3. Organizations drop-down selector

      1. Manually select specific organizations

      2. Choose individual child organizations that should have this trigger active

   4. Tags drop-down selector

      1. Choose to activate organizations which have been given the specified tags

      2. Any future organizations tagged will be pulled in via the tag

• If you don't enable All current and future managed organizations, you must manually add new clients to the trigger when they're onboarded.

• You can't filter organizations by tags in this menu - it's either individual selection, all, or all plus future.

• Even if a trigger is activated for an organization, the workflow will only work if that organization has the required integrations configured and mapped.

• If the workflow uses parent organization integrations like your PSA, you must configure integration overrides on the trigger to give child orgs access to those credentials.

Critical timing

Starting on May 2, 2026, all workflows will default to their critical timing set as False. If you want a workflow to run at a specific time without flexibility, be it a new workflow or an existing workflow, you'll need to manually indicate this in the Critical Timing selector.

Critical timing is Rewst's setting for indicating if a workflow with a cron trigger must be run at a certain time or if there can be allowed variation in when the workflow is triggered. Choose true if the workflow must run at the same time each day. Choose False or None if the workflow's schedule has flexibility. This will adjust the start time, but maintain the frequency of when the workflow is triggered. By default, triggers that share the same schedule are spread across a short window to reduce load spikes and improve performance.

The time window will depend on your schedule's frequency, capped at 30 minutes: */5 * * * * : every 5 min — within ~1 min 0 * * * * : hourly — within ~15 min 0 10 * * * : daily at 10 AM — within ~30 min 0 0 1 * * : 1st of each month — within ~30 min

Modify an existing trigger

To modify an existing trigger, click on the yellow trigger bar. Then, click on the individual trigger in the trigger list. Update any of the settings in the tabs as desired, then click Save Trigger.

Use a trigger on a form

Once the trigger has been created on a workflow, it can then be used on a form. This must be an options generator workflow. The requirements for this can be found here.

The above is a screenshot from a form where a dropdown field has been selected and the output will be based on the workflow output. When running the form, if the client is added on the trigger and the trigger is set on the form, the workflow will run, and the options will fill into the form field.

Core triggers

There are seven key triggers to understand when getting started with Rewst. These triggers cover a range of automation scenarios, from scheduled executions to real-time event responses. In Rewst, we denote these from other triggers by calling them core triggers. Type core into the Trigger Type field to isolate most of these trigger types from the total list.

Core - Always Pass

The always pass trigger allows a workflow to start without conditions. It is commonly used in workflows that do not depend on external events or schedules. It's mostly used with the Test button in the Workflow Builder Canvas, and options generators for forms that need an override for its fields. You might use this trigger when testing workflows, executing a workflow from another workflow without needing a specific event, or populating dynamic options in a Rewst form.

This trigger is most useful for:

• Manual workflow execution: running a workflow on demand

• Subworkflows or completion handlers: workflows triggered by other workflows

• Testing automation: verifying workflow functionality

• Option generators: dynamically populating form fields in Rewst

For more information on option generators, refer to Rewst Foundations.

Core - App Platform

This trigger functions the same as Core - Always Pass. By using this trigger type, you create a clear indication that the intended use case is for Rewst's App Builder. Note that it is only useful in locations where you can select a trigger— Data Tables and Charts.

Core - Cron Job

The cron job trigger initiates a workflow on a predefined schedule. This allows you to automate recurring tasks without manual intervention.

Schedules are configured using cron syntax. Consult crontab guru for help configuring this syntax.

For example, you can configure a workflow to run every Monday at 3:00 PM to generate weekly reports or clean up outdated records.

This trigger is most useful for:

• Scheduled maintenance workflows: clearing stale data, running audits

• Recurring notifications: sending reminders, generating reports

• Automated check-ins: verifying system statuses, updating dashboards

This trigger also uses critical timing.

Core - Form Submission

A workflow can be triggered when a user submits a form. Forms collect structured information, ensuring the workflow has the necessary data to proceed.

For example, you can submit an employee onboarding form to trigger a workflow that creates user accounts, assigns permissions, and sends welcome emails.

This trigger is most useful for:

• Request-based workflows: access requests, service requests

• Intake processes: user registrations, issue reporting

• Approval workflows: leave requests, expense approvals

For help building a form, refer to Conditional fields.

Core - Time Interval

Time intervals can be set to trigger a workflow repeatedly over specified periods. This trigger is suitable for workflows that need to repeat on a regular basis.

• Examples:

  • Every 5 minutes

  • Every hour

  • Daily

  • Weekly

Check out our Use webhook triggers page for a more detailed example.

Core - Webhook

A webhook trigger starts a workflow when external data is received in real time. Webhooks eliminate the need for manual checks, making them efficient for event-driven automation.

The webhook URL serves as a listening endpoint. When an external system like a CRM, ticketing system, or another Rewst workflow sends data to the webhook URL, the workflow is triggered immediately. This enables seamless integration between Rewst and external applications without requiring a direct API connection.

For example, a webhook could trigger a workflow whenever a new customer signs up in a CRM, automatically assigning them an account manager and setting up follow-up tasks.

This trigger is most useful for:

• Event-driven automation: responding to new leads, updating records on status changes

• Real-time notifications: escalating high-priority tickets, alerting teams to critical updates

• External system integrations: syncing data between platforms, processing incoming requests

For more information on webhook triggers, refer to Use webhook triggers.

PSA: Ticket record saved

Note that this is the only common trigger type that does not start with Core, as the trigger name will be specific to your brand of PSA. Search for that in the trigger type list instead.

This trigger is similar to the webhook trigger but is specific to PSA systems. When a ticket record is saved in an integrated PSA, the workflow starts automatically. This includes both newly created tickets and updates to existing tickets.

For example, if a ticket is updated to Escalated, a workflow can trigger an alert to the appropriate team or assign a senior technician.

This trigger is most useful for:

• Automating ticket management: escalating high-priority tickets, auto-assigning technicians

• SLA enforcement: sending reminders for unresolved tickets, auto-responding to specific cases

• Status-based automation: triggering follow-up workflows when a ticket is created or reaches a certain stage

For more detailed information on PSA triggers, refer to Customize PSA ticket triggers.

Rewst triggers

Rewst triggers are additional triggers that can be used across all integrations and relate directly to the Rewst platform. Type Rewst into the Trigger Type field to isolate most of these trigger types from the total list.

Rewst - Added User

The Rewst - Added User trigger starts the workflow when a new user is added in Rewst. The triggering event is when the user signs in for the first time, not when the invite is sent. This trigger is useful for:

• Onboarding automation when new users are added to Rewst

• Sending welcome notifications to new users

• Syncing new user accounts to external systems

• Auditing and logging new user creation events

• Automatically assigning resources or permissions to new users

When this trigger kicks off, it provides the following data in triggering_user_data:

Field	Type	Description
id	string	The user's unique identifier
role	string	The user's role
org_id	string	The organization ID the user belongs to
role_ids	array of strings	List of role IDs assigned to the user
username	string	The user's username
created_at	datetime	When the user was created
updated_at	datetime	When the user was last updated
is_superuser	boolean	Whether the user is a superuser

Rewst - Added User in Whitelist

The Rewst - Added User in Whitelist trigger starts the workflow when a user is whitelisted, or invited, in Rewst. This trigger is useful for:

• Sending custom welcome emails when users are invited to Rewst

• Logging and auditing user invitation events

• Triggering approval workflows before invites are finalized

• Syncing invite information to external ticketing or documentation systems

• Tracking who is inviting users and to which organizations

When this trigger kicks off, it provides the following data in triggering_user_invite_data:

Field	Type	Description
id	string	The invite's unique identifier
email	string	The email address of the invited user
org_id	string	The organization ID the user is being invited to
role_ids	array of strings	List of role IDs assigned to the invited user
created_at	datetime	When the invite was created
updated_at	datetime	When the invite was last updated
accepted_at	datetime	When the invite was accepted - if applicable
is_accepted	boolean	Whether the invite has been accepted
created_by_id	string	The ID of the user who created the invite

Rewst - Crate Published Trigger

The Rewst - Crate Published Trigger kicks off the workflow when a Crate is published in Rewst, allowing you to react programmatically. This trigger is useful for:

• Automating notifications when new crates are published to the Rewst marketplace

• Triggering review or approval workflows when crates are published

• Logging and auditing crate publication events

• Syncing crate publication information to external documentation or communication systems

• Automating post-publication tasks like announcements or version tracking

The Crate will include the following in the workflow execution once triggered.

CTX.triggering_crate_data.crate_id ID of the Crate CTX.triggering_crate_data.workflow_id ID of the parent workflow in the Crate

Rewst - Deleted User

The Rewst - Added User trigger starts the workflow when an existing user is removed in Rewst. This trigger is useful for:

• Offboarding automation when users are removed from Rewst

• Auditing and logging user deletion events for compliance

• Syncing user deletions to external systems (e.g., removing access elsewhere)

• Sending notifications when users are removed

• Cleaning up resources or permissions associated with deleted users

When this trigger kicks off, it provides the following data in triggering_user_data:

Field	Type	Description
id	string	The deleted user's unique identifier
role	string	The user's role (at time of deletion)
org_id	string	The organization ID the user belonged to
role_ids	array of strings	List of role IDs that were assigned to the user
username	string	The user's username
created_at	datetime	When the user was originally created
updated_at	datetime	When the user was last updated
is_superuser	boolean	Whether the user was a superuser

Rewst - Deleted User in Whitelist

The Rewst - Deleted User in Whitelist trigger starts the workflow when a user is deleted from a whitelist, meaning that their invite is removed in Rewst. This trigger is useful for:

• Auditing and logging when user invites are revoked or removed

• Sending notifications when pending invites are cancelled

• Syncing invite deletions to external ticketing or documentation systems

• Tracking invite lifecycle events for compliance purposes

• Cleaning up any resources or pending actions associated with revoked invites

When this trigger kicks off, it provides the following data in triggering_user_invite_data:

Field	Type	Description
id	string	The invite's unique identifier
email	string	The email address of the invited user
org_id	string	The organization ID the user was invited to
role_ids	array of strings	List of role IDs that were assigned to the invited user
created_at	datetime	When the invite was originally created
updated_at	datetime	When the invite was last updated
accepted_at	datetime	When the invite was accepted - if applicable
is_accepted	boolean	Whether the invite had been accepted
created_by_id	string	The ID of the user who created the invite

Rewst - Managed Organization Added

The Rewst - Managed Organization Added trigger starts the workflow when a new parent organization is added in Rewst. This trigger is useful for:

• Automating client onboarding workflows when new managed organizations are added

• Sending notifications to internal teams about new clients

• Automatically provisioning resources or configurations for new organizations

• Syncing new organization data to external PSA, documentation, or CRM systems

• Triggering initial setup tasks like creating default users, permissions, or integrations

• Auditing and logging new organization creation events

When this trigger kicks off, it provides the following data in triggering_organization_data:

Field	Type	Description
id	string	The organization's unique identifier
tid	string	The tenant ID
name	string	The organization's name
domain	string	The organization's domain
is_msp	boolean	Whether the organization is an MSP
created_at	datetime	When the organization was created
updated_at	datetime	When the organization was last updated
customer_id	string	The customer ID
roc_site_id	string	The ROC site ID
managing_org_id	string	The ID of the managing (parent) organization
subscription_id	string	The subscription ID

Rewst - Managed Organization Deleted

The Rewst - Managed Organization Added trigger starts the workflow when an existing parent organization is removed in Rewst. This trigger is useful for:

• Automating client offboarding workflows when managed organizations are removed

• Sending notifications to internal teams about client departures

• Cleaning up resources, configurations, or integrations associated with the deleted organization

• Syncing organization deletions to external PSA, documentation, or CRM systems

• Auditing and logging organization deletion events for compliance

• Revoking access or permissions tied to the deleted organization

• Archiving data or records related to the removed client

When this trigger fires, it provides the following data in triggering_organization_data:

Field	Type	Description
id	string	The deleted organization's unique identifier
tid	string	The tenant ID
name	string	The organization's name
domain	string	The organization's domain
is_msp	boolean	Whether the organization was an MSP
created_at	datetime	When the organization was originally created
updated_at	datetime	When the organization was last updated
customer_id	string	The customer ID
roc_site_id	string	The ROC site ID
managing_org_id	string	The ID of the managing (parent) organization
subscription_id	string	The subscription ID

Rewst - Managed Organization Updated

The Rewst - Managed Organization Added trigger starts the workflow when an existing parent organization is updated in Rewst. This trigger is useful for:

• Syncing organization changes to external PSA, documentation, or CRM systems

• Sending notifications when client organization details are modified

• Auditing and logging organization update events for compliance

• Triggering workflows when organization settings or configurations change

• Updating related resources or integrations when organization data is modified

• Tracking changes to organization names, domains, or other key attributes

When this trigger kicks off, it provides the following data in triggering_organization_data:

Field	Type	Description
id	string	The organization's unique identifier
tid	string	The tenant ID
name	string	The organization's name
domain	string	The organization's domain
is_msp	boolean	Whether the organization is an MSP
created_at	datetime	When the organization was originally created
updated_at	datetime	When the organization was last updated
customer_id	string	The customer ID
roc_site_id	string	The ROC site ID
managing_org_id	string	The ID of the managing parent organization
subscription_id	string	The subscription ID

Rewst - Updated User

The Rewst - Updated User trigger starts the workflow when a user is updated in Rewst. This trigger is useful for:

• Auditing user changes within Rewst

• Syncing user updates to external systems

• Triggering notifications when user roles or permissions change

• Logging user modifications for compliance purposes

When this trigger kicks off, it provides the following data in triggering_user_data:

Field	Type	Description
id	string	The user's unique identifier
role	string	The user's role
org_id	string	The organization ID the user belongs to
role_ids	array of strings	List of role IDs assigned to the user
username	string	The user's username
created_at	datetime	When the user was created
updated_at	datetime	When the user was last updated
is_superuser	boolean	Whether the user is a superuser

Rewst - Updated User in Whitelist

The Rewst - Updated User in Whitelist trigger starts the workflow when a whitelist is updated in Rewst. This trigger is useful for automating actions when user invitations are modified in Rewst, such as:

• Logging changes to user access

• Notifying administrators of whitelist updates

• Triggering onboarding or offboarding workflows based on invite status changes

When this trigger kicks off, it provides the following data in triggering_user_invite_data:

Field	Type	Description
id	string	The unique identifier of the user invite
email	string	The email address of the invited user
org_id	string	The organization ID the invite belongs to
role_ids	array	List of role IDs assigned to the user
created_at	datetime	When the invite was created
updated_at	datetime	When the invite was last updated
accepted_at	datetime	When the invite was accepted (if applicable)
is_accepted	boolean	Whether the invite has been accepted
created_by_id	string	The ID of the user who created the invite

Other triggers

Rewst offers additional triggers for some of our integrations tailored to different automation needs. Explore the available triggers in the trigger type list to find the best fit for your specific processes. Try asking RoboRewsty what each integration-specific trigger does to learn more about how it can be used, or read more about included triggers on each integration's info page in this site.

The contents of the complete trigger type list will depend on your particular integrations