Connect apps to your workflows.
Use events from your apps to start or stop outreach, then send the result back where your team works.
Step 1
Connect an account
In Connections, find Connected apps and choose Connect app. Select an app, authorize the intended account, and check that it appears as connected.
You need workspace owner or admin access. Connected apps use Pipedream Connect for account authorization and app components. Your voice, SMS, and email sending accounts are configured separately under provider connections.
Step 2
Start from an event
Open a workflow in Workflows. Under Triggers and completion actions, choose Add automation, then Start trigger. Select the app, trigger, and connected account.
For example, a new contact event can start a follow-up workflow. Inspect a sample event from your chosen app and map its fields:
- External contact ID
- A stable contact identifier. Use the same identity when configuring a stop trigger.
- Destinations
- The phone or email required by your workflow, plus the recipient's time zone when available.
- Variables
- The values referenced by your message content, such as a first name.
- Only when
- An optional event field and expected value that limit which events start follow-up.
Field paths depend on the app's event payload. A path such as event.contact.id only works when that field exists in your selected event. Each workflow supports one start trigger.
Review and publish the workflow before adding a live start trigger. Saving an automation activates it after setup succeeds. A start trigger runs the latest published version; saving changes to a draft does not change that published version.
Step 3
Stop on a matching event
Add a Stop trigger for an event that means follow-up is no longer needed, such as a contact reaching the intended CRM stage. Map its external contact ID and use Only when to match the relevant event value.
Tremi matches active runs for that contact in the workflow, records the connected stop, and dismisses remaining work. The identity must agree with the start event or the recipient.externalId sent over the API.
A stop prevents later dispatches. It cannot retract a message already accepted by a provider. See run states for the possible outcomes.
Step 4
Act on the result
Add a Completion action, select the app and action, and choose the run outcomes that should trigger it. Configure fixed action properties and map any fields that should come from the completed run.
For example, update a contact after a goal is achieved or create a review task after a provider failure. The available actions and required properties depend on the selected app component.
Use a signed result webhook when your own backend should receive the result directly. Result delivery and connected actions have their own evidence; a completed outreach run does not by itself prove either downstream operation succeeded.
Step 5
Test and inspect
- Simulate the draft in the console before publishing, or simulate a published version through the API. Simulations use 0 credits and do not send through providers or execute connected-app actions.
- Check field mappings against a real event shape using a test contact you control.
- Confirm that the saved automation is active, then send one intentional test event. This is a live test and can contact the mapped recipient or update the connected app.
- Open the resulting run and inspect its trigger, attempts, stop reason, and downstream execution evidence.
If nothing happens
- No run
- Check the connected account, enabled automation, published version, event filter, and required recipient fields.
- Follow-up did not stop
- Check the external contact ID and workflow. The stop event must identify an active matching run.
- No completion action
- Check that the run reached a selected outcome and inspect the action's execution evidence and required properties.
Usage and ownership
A successful connected-app operation uses 1 credit. A start trigger that starts a run uses 2 credits in total: one for the trigger and one for the workflow start. Provider-accepted outreach attempts use additional credits. A stop trigger is charged only when it stops at least one active run; a completion action is charged after it succeeds.
Your team owns account permissions, event selection, field mappings, recipient consent, and the effects of configured actions. Tremi records orchestration and execution evidence; connected apps and sending providers retain their own terms and service limits.