Appmint Automation: Triggers, Actions, Testing and Run Monitoring

▶ Play video

Watch on YouTube ↗

Automation Navigation and Test Preparation

Cedar & Form wants each new design inquiry to produce a follow-up task. We will build that small chain, run it once without an event, then create a real test lead and trace its event to the saved task. The difference matters: a manual run can test an action, but only a real event supplies the originating record and proves the trigger connection.

Current local capture, 2 October: Dashboard, Workflows and Workflow Builder are visible. Open More to find Runs & Logs and Templates when the navigation is compressed. The empty dashboard is this rehearsal organisation before creating the test, not missing product capability.

Use a training organization with Automation access and permission to create/read leads and tasks. You need a colleague account only when testing assignment, and controlled inboxes/phone numbers only for the communication extensions. The first exercise sends no messages and uses fixed text, so it can establish record persistence before provider configuration. Example customer values are Rowan, Lee, Cedar & Form, and [email protected]; the example email is data, not a deliverable address. Replace it with a controlled test inbox if a later communication action will use it.

Open AI, IVR, Automation → Automation. The heading is Smart Automation. Dashboard summarizes activity; Workflows lists saved definitions; Workflow Builder edits their steps; Runs & Logs provides execution history; Templates supplies starting shapes. Inside this module a workflow means an automation definition. Appmint's separate Workflow module is the staged process board, with different controls.

Keep a record of the automation ID, each run's execution ID, the created lead ID and task ID. These allow you to distinguish two successful tests from an accidental duplicate. Source review establishes the controls and current handlers described here, not a completed run. This draft retains known unavailable/stubbed paths explicitly, including places where an apparently successful action does not currently persist a business record.

What you will check

Concept illustration, not an application screenshot. The run log answers whether the steps ran; opening the returned task answers what was saved. Create Task writes the task before the ending step. A manual Run once has no triggering-record context.

Before creating the draft, open Database → Data Explorer and confirm you can open the Task collection. This is where you will inspect the output. If the collection or Automation is inaccessible, have the organisation administrator check your assigned access rather than creating the same task in an unrelated workspace. For this first exercise, use fixed text, leave Assigned To blank and add no email, SMS or call actions.

Drafts, Templates, JSON Import and AI Editing

Choose New Workflow. In the builder's heading replace Workflow Name with Cedar & Form — inquiry follow-up, set Slug to cedar-inquiry-follow-up, and enter description Create one follow-up task when a new training lead is saved. A blank workflow starts as a draft. Keep its identity distinct from the separate seed workflow used later.

Current local unsaved draft: the name, slug, description and Save belong to the definition; Add Trigger/Action/Condition/End/Block construct its steps. No execution exists just because this editor is open.

Current Templates view: inspect the steps and placeholders before using Use This Sequence. These cards are starting definitions; this capture does not prove their delivery or handler support.

For a template-based start, return to Templates, inspect the template's displayed steps, then choose Use This Template. Email-sequence cards use Use This Sequence and the timing cards use Use Smart Template. Review every resulting step in the builder: sample recipients, template names, action names and timing are starting data, not verified configuration. Some legacy template action names have no runnable handler. Replace or remove a rejected step based on the validation message; do not activate a sequence solely because its template card looks complete.

The page-level Import route accepts one JSON object or an array. Its current importer expects top-level name, trigger and actions, with optional description, conditions and isActive; it does not simply accept an arbitrary exported BaseModel or the builder's steps array. The current importer passes this legacy shape directly to record creation without converting it to the engine’s steps array. A successful import count therefore cannot establish a runnable definition. No tested legacy import fixture is supplied in this course: treat the route as a configuration/migration limitation, not a completed import exercise. Do not import an arbitrary active automation to work around it. A partial batch can report fewer successful imports than supplied objects, so inspect every saved result in Workflows. Invalid JSON format means parsing failed; a valid JSON object can still fail structure/engine validation. Do not repeat an entire partially successful batch until you have identified which definitions already exist.

The AI bar sends a request with the current automation context. A useful request is Add a follow-up task for a newly created lead, keep this as a draft, and do not add customer messaging. Send with Enter; Shift+Enter permits a multiline request. Command history revisits prompts and Stop generating interrupts generation. After any AI change, inspect the actual type, configuration, recipient and branch destinations in the builder, save, reopen and run the same verification as a manual edit. Generated prose or a suggested step is not runtime evidence.

Triggers, Task Actions and Manual Tests

Local repair verified — 4 October: An earlier Wait/Delay → Create Task → End (Success) run created its task and then failed with Unknown step type: end. The local runner now handles terminal steps: regression tests and two real local API executions confirm success/failure endings stop later steps. The original combined wait exercise has not been replayed with its ending enabled, so its screenshots remain historical evidence. Always inspect the task output before retrying a failed run; an ending cannot undo an earlier write.

1. Choose the record trigger

Choose Add Trigger, open the new row's selection menu, type Record Created in Type to filter…, and select Record Created. Open the row's configuration control to reveal Step Configuration. In Datatype, select the organization's lead collection. The current rendered form uses Datatype, even though the option-description library sometimes calls this Record Type. The Data button near Save opens Data Fields, which helps locate real collection fields; it does not supply an event payload to a manual run.

Current unsaved example: select Record Created from this menu, then open the row’s Configure gear. This is selection, not activation.

2. Add the task action

Choose Add Action, select Create Task, and configure Title Cedar manual follow-up 01, Description Review the new inquiry and record the next action., Priority Medium and Category cedar-training. Set a future Due Date if desired. Leave Assigned To empty for the first persistence test. This form offers symbolic options such as Current User and Sales Team; the current handler writes the selected value without establishing resolution to an actual colleague. Do not promise that choosing Current User puts the task in your Workspace My Tasks. This task is associated with the triggering record when that context exists, not automatically with a Workspace.

Current controlled example: Title and Description are fixed text, Assigned To is empty and Priority is Medium. The generated field is labelled Title, even though the schema description calls it Task Title. Save before leaving the builder.

3. Save the first action-only test

For this first test, save Create Task without an explicit End row. This is the configuration whose successful task creation and independent readback were verified. End (Success) is available in Add End and its terminal behavior has now passed the local repair checks. Keep this first exercise action-only to match the recorded task-persistence walkthrough; add an explicit ending when practicing branches.

Save, return to Workflows and reopen the saved definition to check the task fields. If the list briefly says no workflows after a successful save, reload before creating another copy; the saved draft appeared after reload in the current walkthrough. Keep the workflow a draft for the manual test.

4. Run the saved draft once

The monitor distinguishes Run once from Start. Run once executes the saved draft now without a triggering record. Start enables its configured event trigger. For the first action-only test, keep the definition inactive; do not turn on unrelated customer-facing steps.

Open the workflow name or its monitor control. Choose Run once. The control explicitly runs without a triggering record and works on a draft. Open the resulting run, read Step by step, and capture the Create Task output's task ID.

5. Find the actual saved task

Open Database → Data Explorer, search collections for task, and select Task. In Table view, inspect the loaded rows for Cedar manual follow-up 01; use Load More if needed. The visible record-search/status controls are not currently applied, so do not depend on them to filter this list. Choose Edit on the candidate row and compare Title, Description, Status and Due Date. Cancel to close without changes. On that same row choose Edit Raw JSON; match its top-level sk to the returned taskId and inspect data.source=automation, priority and executionId. Cancel without editing. The visible title identifies a candidate; the matching ID proves it is the task from this run. If the name already exists, change the action title to an unused suffix before another manual run: the handler also uses this title as Task name, whose schema requires uniqueness.

6. Check validation without activating an incomplete workflow

For a validation exercise, clear Title in this inactive draft and Save. An incomplete draft may save; runnable validation is enforced when you choose Start, and when saving an already active definition. Return to its monitor and choose Start once. It should refuse activation with the missing-title problem. Use Fix, restore the title, Save and reopen. Do not activate it yet: configure the separate event-run title in the next section first. Draft persistence, permission to activate and successful execution are different checks.

The locally tested draft was Course Automation — manual task 20261002, containing only Create Task. Its unique output title was Course enrichment manual task 20261002-01. It remained draft after one successful run. These are evidence identifiers, not required learner names; give each new test a unique name and inspect prior results before retrying.

If Edit opens the saved builder without its expected step rows, do not save the empty-looking form. Reload the page and inspect the same saved definition again. This recovered the saved Create Task row in this local walkthrough; report a persistent blank editor rather than replacing the definition.

Independent current readback: sk matches returned taskId 6ac05ee2412569923b11e662; source is automation and executionId matches exec_1790992098498_45i55r. Assigned To is null, priority medium and task status pending. The raw viewer was closed with Cancel without edits.

Activation, Event Context and Record Verification

A manual run tests an action. A record-created run also proves that the trigger receives a real record and passes its identity into the action. Use your training organization and the task-only definition from the previous chapter. Keep email, SMS and other communication actions out of this exercise.

1. Enable the lead trigger

Edit Create Task and use a new unused Title, such as Course event follow-up 20261004-01. Save. In the trigger row choose Record Created, open Configure, and choose lead in Datatype. Disable any wait used in the earlier exercise; leave an explicit End row absent or disabled to match this recorded action-only exercise; endings are locally repaired, but this event exercise did not verify one. Save, return to the workflow monitor and choose Start.

Check for active and Listening for lead created. In this walkthrough the success toast appeared before the monitor updated; reloading and reopening the saved workflow showed the persisted active state. Do not press Start repeatedly because an old badge has not refreshed.

The Errors card includes an earlier ending failure. Trigger readiness is shown by the listening status; old errors remain in the selected history window.

2. Create one harmless test lead

In another Studio tab, open Database → Data Explorer, search collections for lead, select lead, and choose Add Record. Use the form window’s Maximize control if the fields are squeezed into a narrow drawer. Enter:

Leave the default Pipeline default, Stage new, Lead Status New and unrelated fields unchanged. The example email is deliberately non-deliverable; this exercise has no send action. Email Address and Source are required: an attempted save without them produced a validation error. Enter them, then choose Save once and confirm the lead row appears.

This is the same saved lead reopened for a readable capture. It was closed with Cancel after inspection.

3. Match the event, run and saved task

Return to the workflow monitor and allow its automatic refresh to show the new run. Open the row marked by event, not one of the earlier by hand rows. Under The data it ran with, verify triggerEvent=data_created, dataType=lead, and the source record ID in dataId and record.sk. Under Step by step, read Create Task’s taskId.

Open Data Explorer → Task. Find the newly configured task title in the loaded rows and choose Edit Raw JSON. Match its sk to the run’s taskId, data.executionId to this run, and owner.id to the lead ID; owner.datatype should be lead. Close with Cancel.

The local run exec_1791091891281_7rgvbimby created task 6ac1e4b319ec5a8a773c95a8, independently matched to lead 6ac1e4b319ec5a8a773c95a5. That completes this fixed-title event-to-task test. The description in the capture was retained from the earlier wait exercise; the disabled wait did not execute in this event run.

Choose Stop in the workflow monitor after this test so later training leads do not keep creating the fixed-name task. This stops future trigger processing; it does not delete the saved lead/task or erase earlier runs.

4. Extend the example with event variables

Now inspect the real event data before adding variables. The engine resolves {{path.to.value}} from run variables; unresolved paths may remain literal text. Use the exact nesting displayed under The data it ran with. For example, use {{data.values.email}} only for a form event that actually includes that shape. A record event might expose a different object. For the next event, first confirm The data it ran with contains the source record as record with its sk. If so, change Title to Cedar follow-up {{record.sk}} and put Lead {{record.sk}} in Description. This generates a different task name for each distinct lead. If that exact path is absent, keep a new unused fixed title such as Cedar event follow-up 02 while inspecting the actual payload instead of guessing a variable. Save, change the seed lead to a new name and unique training email, Run once on the seed, and verify the new task contains the resolved value. Replaying the same lead can still collide with the same generated task name; this exercise is one task per new lead, not proof of idempotent retries. Fixed sample text working on Run once does not validate a dynamic field mapping.

The payload shape above was observed in the real lead event. Dynamic title substitution, a second event, and the negative test after Stop still need their own replay; the fixed-title success does not prove those alternatives. Create Lead inside another automation remains an alternative documented path, not the route demonstrated here.

Record, Contact, Form, Appointment and Pipeline Triggers

A trigger is useful only if the application or connected service emits the event with the fields you need. Build alternate drafts with the same harmless Create Task action, changing one trigger at a time. After each change, Save, Start, perform the originating action once, and find its matching run by time and record ID. Also perform a nonmatching event to check the filter. This same operation sequence applies below; the configuration and initiating action differ.

Current unsaved draft: open the row’s Configure gear to reveal Datatype. Choose the actual collection; this empty picker does not establish event registration or a successful trigger.

For Record Updated, select Data Type and use Watch Specific Fields such as status,priority only after inspecting the real source field names. Change one watched field and one unrelated field on separate tests. The schema and trigger handler use differently named filter structures in places; treat enforcement as a live test, not an assumed guarantee. Record Deleted needs a disposable record with its ID recorded before deletion; the run must retain sufficient context because the original record may no longer open.

Contact Tagged selects tags and an any/all match where offered. Add the selected tag to the controlled contact and compare against an unrelated tag. Score Changed offers threshold/direction in the option library; confirm the actual configuration form and event producer before relying on it. In the current server registration not every offered trigger has a dedicated implementation. A selection that shows only Configuration (JSON), or fails to register, remains an unavailable route until its actual contract is verified.

For Form Submitted, configure Form ID, Source Filter, Required Fields and Submission Data Filter using the actual published test form. Submit that form from its real page, then inspect the submission and run. Form Viewed and Form Abandoned require separately emitted view/abandonment events; a successful submission does not prove either. The same distinction applies to Appointment Booked, Appointment Cancelled, Appointment Completed and Appointment No Show. For booked, choose the real Calendar ID, Appointment Type and Time Range and complete a real test booking; for the others change the corresponding reservation lifecycle and inspect the event rather than just editing text.

For Pipeline Stage Changed, choose the source pipeline and stage filters shown by the form, then move a disposable opportunity and check its prior/new stage. Deal Won and Deal Lost must match the actual registered event name and producer; their catalogue presence is not sufficient. If no run starts, inspect workflow activation, event type, datatype/record ID and filter values in that order. Preserve a missing producer as a product gap instead of inventing an event with a manual run.

Communication, Website, Webhook and Scheduled Triggers

Email offers Email Opened, Email Link Clicked, Email Replied, Email Bounced and Email Unsubscribed. Start with a controlled message sent by the configured service, record its message ID, and choose matching Email ID/Template ID or link filter where the form supplies them. Open or click from the test recipient and inspect both the provider tracking event and Automation run. A mailbox preview or privacy proxy can affect open events; a run is evidence of the received event, not proof a person read the content. Reply, bounce and unsubscribe each need their own real event test.

SMS offers Received, Replied, Failed and Opt Out; phone offers Incoming Call, Missed Call, Call Completed and Voicemail Received. Choose the configured Phone Number/Routing where available, then set only filters you can reproduce, such as Caller Pattern, business/after-hours, ring duration, call direction or voicemail transcript. Test with controlled numbers and inspect the phone/SMS record and resulting run. These require the connected number, provider callbacks and appropriate recipient access; Automation does not establish a phone account by selecting a trigger. A transcript requirement cannot pass until transcription actually completes.

For Page Visited and Button Clicked, use the actual published page URL or button ID/selector and a site with the required event instrumentation. Visit/click in a visitor session and inspect the produced event. Loading the builder preview alone is not visitor evidence. No Activity exposes Days of Inactivity, Activity Types and Exclude Tags; use a controlled contact whose dated history qualifies. Engagement Threshold similarly needs a real scoring source and observed event. Do not replace elapsed-time evidence with an edited screenshot or assume the label schedules a scanner.

For Webhook Received, Save the definition before copying its displayed Webhook URL with Copy URL. The URL includes the definition slug/ID, step ID and organization. Inspect Webhook Endpoint, Authentication, mappings from Source Field to Target Field, and validation fields as supplied by the form. Send a controlled JSON request from your integration client to the displayed URL, using the deployment's actual authentication contract, and inspect the received variables. The Authentication selector alone is not proof the inbound handler enforces it; test missing/invalid credentials against the real handler before using sensitive payloads. Never hand-construct a production URL from an illustrative example.

For Recurring Schedule, first manually test a separate Create Task draft with an unused fixed title. Before scheduling it, change Title to Cedar timed follow-up {{scheduledAt}}: the dedicated time-trigger service supplies scheduledAt on each scheduled run, giving distinct task names. Manual Run once has no scheduledAt, so do not use that variable as a manual fixture. Reopen the saved action and confirm each real scheduled run resolves it before leaving recurrence active. Then choose Frequency Daily/Weekly/Monthly/Yearly, Days (weekly) such as monday,wednesday, Day of month (monthly), Time, Timezone America/Chicago, and optional End Date. Set the first trial to the next useful test time, Save and Start, then verify an actual scheduled run. Empty timezone means UTC. Specific Date/Time is implemented through the automation scheduling service. For a one-time alternative, make a separate inactive definition with one uniquely titled Create Task action and End (Success). Add Specific Date/Time; set Date to today, Time at least five minutes ahead, select your actual Timezone, and leave Recurring off. Save, reopen, then Start. The start response should report the scheduled instant; in Schedule → List inspect the generated automation-owned simple schedule. After it is due, inspect the Automation run and the new Task by returned ID. Past one-off times produce no usable scheduled job; choose a future time and Start again after inspecting existing work. Recurring on this particular trigger means the selected date repeats annually, not daily. A separate yearly test needs its own next-occurrence check. This route is documented, with live execution still pending. Date Field Trigger is offered without a matching current form schema/registered handler found in this audit; do not promise birthday/date-offset execution. Use a verified recurring workflow or the source module's supported schedule path until this route exists.

Current unsaved editor: Frequency, weekly days, day of month, Time, timezone and End Date appear here. America/Chicago is placeholder text, not a saved choice. The lower form continues below this viewport. This image does not prove a scheduled run.

Record and CRM Actions

Use a separate draft for each business mutation so a failure cannot be hidden among unrelated successes. For Create Record, select Datatype and enter Data Fields as a JSON object with fields from the actual collection. For a training collection with a title field, an example is {"title":"Cedar follow-up record"}; do not use this against a schema requiring other fields. Save, Run once, retain the returned ID and reopen the record. This generic write does not invoke every specialized business workflow.

Update Record currently has a configuration-contract gap. Its form writes Data Type (datatype), Record ID (recordId) and Fields to Update (fields), but the registered handler requires collection, an object filter and an object update. The current save normalizer does not translate them. Filling that form is therefore not a working update recipe, and Create If Not Exists is not an implemented upsert promise. Use the owning record’s Edit → Save operation for a real change until the form/handler contract is fixed and rehearsed. The intended narrow backend contract is a named collection, a filter containing one actual sk, and an update of the actual data.field; do not broaden the filter to get past validation. Delete Record exposes Collection and Which records. Use a restrictive filter containing the disposable record's actual sk, verify it selects only that record, and never leave it empty. Confirm both its disappearance and that the neighboring record remains.

Create Lead was the working documented fixture route. The offered Update Lead, Qualify Lead, Disqualify Lead and Convert Lead forms accept a Lead ID and changed fields, qualification notes, disqualification reason, or customer/conversion values respectively. Configure a disposable example, but do not rely on these actions for a completed lifecycle: their inspected handlers still have service integration commented out and construct success-shaped results. The recovery is to use the owning CRM module's real lifecycle operation and verify it there, or have the missing integration fixed before automating it. A generic field update is not equivalent to lead conversion.

Current unsaved Create Lead form shows first/last name, email, phone and company placeholders with Source, Status and Priority. These placeholders are examples, not verified event mappings. This view is the upper portion; lower options require scrolling. No lead was created by opening this form.

Create Ticket has a local persistence repair (4 October 2026). The action now calls the same ticket-creation service used by CRM and returns the saved ticket ID and number. Current builder fields Title, description, priority, category, reporter name/email and assignee are mapped to that service; older subject/assignedTo inputs remain compatible. Unresolved template bindings and failed saves return errors instead of fabricated success. Eight focused tests passed through the ticket service with isolated storage and mocked notifications/workflow; a complete live automation replay remains pending.

To check it in your local installation, create a disposable automation with Create Ticket, enter a distinctive Title, description and priority, then save and run once. Inspect its returned ticket ID and number, open CRM → Support, locate that exact ticket, and compare title, reporter and assignment. The independent ticket record is the success check. Saving the action configuration alone does not establish creation, and the focused tests do not prove notification delivery.

Update Ticket and Create Reservation / Update Reservation / Cancel Reservation still have separate incomplete handlers. The reservation configuration includes type, start/end, service, customer and location, but those handlers lack persisted service calls and availability checks. Use the actual Support or reservation interface for these changes until the missing integrations are fixed. Never treat a success-shaped action result as proof that the record changed.

Get Record is offered, but currently falls back to JSON configuration and its handler returns explicit mock data. It is not a reliable read-before-update step. Open the actual record in its owning module/Database for verification; retain the integration gap. These distinctions let you use implemented generic writes and Create Lead without assuming every neighboring catalogue action has the same maturity.

Assignments, Tags, Scores, Opportunities and Sequences

Add Add Tag after a real record trigger, enter Tags to Add cedar-follow-up, optional Tag Source, and an expiry only if temporary tagging is intended. Save, trigger a new test event and inspect the source's saved tags. For Remove Tag, enter Tags to Remove, leave Remove All Tags off, add a reason and verify that an unrelated tag stays. Explicitly targeting one tag is a useful regression check against an overly broad removal.

Assign to User supports fixed and team assignment in its handler. Before configuring it, record the target record ID/type and a real user or populated team. Use specific assignment for the first test; compare the persisted assignedTo with the actual account. Team modes need real candidates and can fail with No one to assign to. Add the missing team members or select the intended existing team and retest on a new disposable record. A handler's notification flag is not proof an assignee received a message; inspect the recipient separately.

Current unsaved form exposes a user-ID placeholder and an unlabeled toggle. user_123 is not a real assignee. The current rendering lacks several labels; identify the real account and verify the handler contract before testing. No assignment or notification was executed.

Create Task persists a task as used in the first example. Complete Task is offered but has no registered action found in the current module; use the actual task's supported completion UI and verify status until the automation action is implemented. Calculate Score has a configuration form for Scoring Model, Scoring Factors and Weightings, but the current utility handler contains unfinished rule calculation and score persistence. Update Score is also offered without a registered implementation found. Configure a disposable draft to expose the limitation; do not report a changed customer score without reading the real record.

For Create Opportunity, choose the actual Pipeline, Stage, Deal Value ($), Opportunity Title Cedar collection inquiry, assignee/source where appropriate, Save and run with the intended contact/lead context. The handler persists this opportunity using a lead-backed record; follow the returned ID rather than assuming a separate opportunity datatype. Move Pipeline Stage needs its actual Opportunity ID, Target Stage, optional Notes and Notify Owner. Run once, open the corresponding pipeline record and confirm the new stage. The offered Close Deal form has Opportunity ID, Won/Lost, reason and value, but no registered close_deal action was found; perform final closure in the supported CRM interface until integrated.

Add to Sequence and Remove from Sequence are offered but lack current form schemas/registered handlers in this audit. Do not confuse their labels with a verified enrollment service. Add Activity has a handler with unintegrated persistence, and Add Note uses a catalogue key different from registered create_note. Inspect validation and preserve those gaps rather than claiming a timeline entry appeared. For a real note, use the record's supported Notes interface and confirm it is saved.

Email, SMS, Broadcast, Phone and IVR Actions

This advanced section requires configured sending accounts. The Phone + IVR + SMS course covers the phone route, and AI Employees + AI Assistant covers assistant setup. Organization email/provider setup and Broadcast audience/template setup do not yet have a complete linked prerequisite in this pack; keep those branches incomplete until that setup and one controlled delivery are recorded.

Start with Send Email in a separate inactive draft. In To, enter a controlled inbox; choose an existing Email template, or leave it empty and fill Subject Cedar & Form test follow-up and Email Content Your training inquiry has reached our team. The form displays From Name, From Email, Reply To, Track Opens and Track Clicks. In the inspected shared send handler, only Track Opens is consumed under that name; sender uses config.from, and the form’s fromName, fromEmail, replyTo and trackClicks are not mapped. Do not expect those displayed fields to override the actual organization/provider sender or enable click tracking. Check the delivered message’s From and Reply-To headers explicitly. Sender/provider setup and verified delivery are required before this branch is complete. Save and Run once, then inspect the message record and receiving inbox before replacing To with a verified event variable. A provider acceptance or tracking event is distinct from inbox delivery.

Current unsaved form: recipient, template and message fields are visible; no email was sent. Some field labels are missing and only placeholders appear in this renderer. Do not treat placeholders as supplied values or assume a variable path exists in every event.

Send SMS needs To Number, SMS Message and configured From Number. The displayed From Number writes fromNumber, while the shared handler reads from; no alias mapping was found. Treat per-step sender override as unresolved. Use a real controlled recipient number and keep the message within the form's 160-character limit. Inspect the SMS record/provider status and the device. Send Notification chooses Send By Email, SMS, Push, In-app or Slack, with To, Subject, Message and optional Template. Test only a channel already configured for the organization and recipient. Schedule Notification is offered without a registered handler found here; use a verified wait followed by Send Notification instead, and prove both waiting and sending.

For Send Broadcast to a Group, first have a reviewed Broadcast record with a test audience, approved sender and message/template. The action's Broadcast picker selects that record. Inspect the audience in Broadcast immediately before the run: the current audience is resolved at execution. Save, run once, inspect the broadcast's per-recipient results and a controlled inbox. Do not select a real customer audience for a configuration test. The action does not create the audience or provider connection merely by selecting the record.

Make Phone Call exposes Call, Caller ID, Call Script, Voicemail Message, Transfer To, Record Call and Max Duration. Use an enabled phone configuration and controlled number, then verify the call record and actual device. Schedule Call uses Assigned To, Call Time, Call Type, Notes and Send Reminders; inspect the saved scheduled object and its eventual handling. A scheduled call record is not evidence the call occurred.

The IVR catalogue supports Speak Text, Collect Input, Play Menu, Transfer Call, Forward/Ring Group, Hangup, Play Audio, Record Audio, Voicemail, Send SMS, Send Email, Collect Payment and AI Assistant. These steps need a live inbound-call context and configured routing/provider; Run once has no caller and is not an IVR demonstration. Build a disposable routing flow with IVR: Speak Text (Message Welcome to the Cedar test line, voice/language), IVR: Collect Input (Prompt, dtmf, one digit, timeout, Save As Variable), then an explicit success/timeout next step and IVR: Hangup. Call the test number and verify heard prompts, entered digit and both paths. Use the real current schema where present; IVR options whose typed form is absent show Configuration (JSON) and require an audited handler contract before configuration can be finished.

For a menu, map each selection to a real next step and configure invalid/timeout behavior. Transfer needs a real phone/agent/queue destination and failure message; Forward/Ring Group needs real targets, sequential/simultaneous mode and no-answer fallback. Audio playback needs a reachable supported file, recording needs a saved output variable/finish key, and voicemail needs a real recording and notification destination. Payment requires a configured provider payment connector and test-mode transaction proof; AI handoff requires a runnable assistant and fallback. Each extension needs its own live call and persisted output. Keep untested provider branches explicitly pending rather than treating the registration of an IVR handler as a passed call test.

Conditions, Branches, Jumps, Waits and Endings

Local repair verified — 4 October: An earlier Wait/Delay → Create Task → End (Success) run created its task and then failed with Unknown step type: end. The local runner now handles terminal steps: regression tests and two real local API executions confirm success/failure endings stop later steps. The original combined wait exercise has not been replayed with its ending enabled, so its screenshots remain historical evidence. Always inspect the task output before retrying a failed run; an ending cannot undo an earlier write.

Before each manual test that creates a task, replace its Title with an unused fixed name, such as Cedar wait test 01 or Cedar retry test 01. Record that name and the returned ID. The handler uses Title as the unique Task name; an unchanged manual title, or an event variable with no manual event context, can fail independently of the wait/condition being tested. Increment the suffix only after inspecting whether the previous run already wrote its task. This does not make retries idempotent.

Current unsaved draft: Add Condition opens a row; its selection arrow exposes If/Then Branch, Switch/Case and field/tag/score checks. Selecting a condition is not proof that either branch ran.

Add two endings first so branch destinations exist: End (Success) with a useful success message, and End (Failure) with a specific Failure Message. Add Condition → If/Then Branch before the action to choose which path runs. Select an actual Field, Operator, Value, IF TRUE - Go to Step and IF FALSE - Go to Step. For example, once you have observed a data.priority path in the real event, compare it with high and route high-priority records to the follow-up task while other records go to the non-action ending. Use the path that is actually present, not the illustrative path if your event differs.

Test one matching and one nonmatching record and inspect Step by step for the actual path. Check Field Value supplies a similar focused comparison. Check Tag Exists and Check Score are offered alternatives, but check their exact registered name/schema and real source data before relying on them; score-related handlers and keys have gaps. Switch/Case uses Field to Switch On, Cases and Default Step (no match). Create an explicit default so a new/unexpected value has a deliberate outcome.

Filter Records is offered but lacks a matching typed schema. Its registered filter handler's contract must be checked before entering JSON. For a single-record decision, use the typed If/Then Branch route. Go To (Jump) has Jump To, Target Step, Target Block and optional Jump Condition. Step destinations are populated from the current workflow; block target options are not fully populated by the schema helper. Prefer a verified step target, inspect that it still exists after edits, and avoid a cycle that cannot reach an ending.

For Wait/Delay, choose Add Action → Wait/Delay, then the row’s Configure gear. Set Duration 1, Unit Minutes and the intended Timezone; inspect any Skip Weekends choice against real runtime behavior. Add the wait before Create Task, Save and Run once. Open the run while waiting, then after it resumes and verify the task was created once. Wait Until Date sets a future Target Date and Timezone. Wait for Reply chooses Message Type, Max Wait Time/Unit, Reply Keywords and Timeout Action; it needs an actual correlated email/SMS sent earlier in the flow. Wait Until Email Opened similarly needs the workflow's sent email, Wait at most, Unit and the no-open action. Test both an actual response/open and a timeout.

Actual local configuration: Duration 1, Unit Minutes and Timezone UTC. The Skip Weekends toggle remains off. Some field labels are faint; the values shown are entered settings, not placeholders. The run resumed after its one-minute wait.

Wait Until Condition uses Condition to Wait For, Max Wait Time/Unit, Check Interval and Timeout Action. Observe the waiting state before changing the test record to satisfy the condition; inspect that the run resumes only as intended. Wait for Event is offered without a registered handler/schema found in this audit, so leave it pending. End (Failure)'s Error Handling options include log/retry/notify/rollback, but those UI choices are not proof of transaction rollback. Verify actual side effects independently; an ending cannot undo an already delivered message merely by naming a rollback option.

Reproduce the recorded wait-and-task exercise

To match the retained wait-and-task evidence, leave the End row absent or use its Disable control. This is the configuration recorded below, not a current requirement to avoid a broken ending. Open Create Task’s Configure gear and enter a new unused Title; the failed test already created its original task. Save, reopen the definition, and verify the ending shows disabled and the new task title is retained. Keep the workflow a draft.

Choose Run once, observe waiting, and then open the newest completed run after the configured minute. This is a new execution, not a retry of the old failure.

The verified run exec_1791091308415_0nnajz completed with its ending disabled before the repair. Its task output was independently matched in Data Explorer to 6ac1e2a87cbebaaf0dd3e278, with pending status and the same execution ID. The monitor’s Errors panel still includes the earlier failed run in its date window; that historical error does not mean the newest run failed. The ending dispatcher is now locally repaired, with separate terminal-only API proof. This screenshot proves the wait and task outcome only; it does not prove a post-repair run with an enabled ending.

Retained independent readback: task sk 6ac1e2a87cbebaaf0dd3e278, status pending, source automation and executionId exec_1791091308415_0nnajz match the completed wait run. The End step was disabled in that run. Close this raw record with Cancel when only inspecting it.

HTTP Integrations and Advanced Action Limitations

Send Webhook has a real HTTP handler, but its current editor and handler disagree on JSON values. The form stores Headers, Request Body and Auth Credentials as text. The inspected handler expects objects: it spreads Headers, reads properties such as token from Auth Credentials, and serializes the body as JSON. The current save normalizer does not parse those three text fields. Consequently, pasting an object-looking string can produce character-index headers, a JSON string instead of an object payload, or missing authentication. This is an application integration gap, not a successful webhook tutorial.

For configuration inspection, create an inactive draft with Send Webhook, select HTTP Method POST and inspect these fields. Do not activate the example or claim delivery. A correct intended request would carry header Content-Type: application/json and an object body {"source":"cedar-training","message":"inquiry received"}. A receiving endpoint must record that exact object and return a response correlated to the run. This course currently has neither a verified form fix nor a controlled receiving endpoint; the request/response demonstration remains incomplete.

After the contract is corrected, the required demonstration is: enter one controlled endpoint, save/reopen the actual values, run once, compare the received method/headers/parsed object with the request, then deliberately reject one field with a 400 response and show the corrected retry. Authentication must be verified at the receiver, not inferred from its selector. No fixture URL is supplied here because none has been rehearsed. Do not use a public endpoint with credentials or customer data to fill that gap.

Transform Data, Set Variable, Team Alert, A/B Test Split and Run Custom Code remain visible catalogue choices. Set Variable and Transform Data lack matching typed schemas and registered actions found here; Team Alert has a form but no registered action. For an internal message use an implemented Send Notification channel and a controlled recipient. For simple field mapping use the implemented action's fields and observed {{...}} variables; there is no demonstrated general transformation engine to promise.

A/B Test Split is offered under ab_test, while a differently named ab_test_split schema exists and no action was registered under the offered key. The custom-code form accepts Custom Code, Language JavaScript/Python/Webhook Call and Timeout (seconds), but custom_code is not registered in the inspected engine. These are configuration surfaces, not runnable capabilities. On a disposable draft, selecting them and Save/Start may produce is not something the engine can run. Keep the draft, capture the named problem, remove the unsupported action and keep the external-service alternative pending until the Send Webhook contract above and the receiving endpoint are verified. A missing internal handler and a broken external handoff cannot validate each other.

Do not silently translate an unsupported choice into a supposedly equivalent custom JSON contract. The fallback Configuration (JSON) accepts syntactically valid configuration but cannot create a missing handler. This distinction is what lets you diagnose a product gap instead of endlessly trying different field values.

The separate HTTP Request choice currently opens this JSON-only fallback. Choose Add Action → HTTP Request → Configure to inspect it, then leave the draft inactive. It is not the Send Webhook form described above and does not become runnable because its JSON parses.

Current unsaved HTTP Request shows “Configuration for this step type will be available soon” and Configuration (JSON). This is a visible product limitation, not a functioning endpoint demonstration; no request was run.

Step Order, Blocks, Enabled State and Validation

The numbered rows show execution order. Use row Move up / Move down controls or drag the actual step above/below another; + Insert Step Here inserts a trigger/action/condition/end at a specific point. After inserting, select the real catalogue action and configure it: a label alone is not an action type. Each row's enabled control lets you temporarily disable a step without deleting its configuration. Save and reopen to confirm the enabled state, then inspect a test run to see that the step is skipped as intended.

Current unsaved example: Create Task is row 1 and end_success is row 2. The second row shows up/down, insert, configure, disable and delete controls. Creating this layout does not validate its missing task configuration or branch targets.

Choose Add Block, rename New Block to Follow-up preparation, and use each row's Assign to block selector. Clicking a block makes it ACTIVE, so newly added steps go into that block until you clear the active selection. Collapse a block for readability; collapsing does not disable its steps. No Block removes membership. Deleting a block containing steps is refused with an instruction to remove or reassign its steps first. Reassign the rows, then delete the now-empty block and confirm. Inspect actual order after grouping; visual organization must not obscure the intended branch path.

Remove only a disposable step when practising Delete. Check every condition/jump/IVR next-step target that referred to it and choose a replacement before saving. Save, reopen and compare the final trigger, configuration, ordering, enabled flags and branch destinations. An inactive unsupported step can be useful as a design note but must not be represented as coverage of working functionality.

Validation problems name a step and reason. Choose Fix to open and focus that step. Correct missing required fields, invalid configuration or unsupported type, Save and recheck. The server validator inspects runnable enabled steps and registered actions/conditions; passing that check cannot establish that a downstream service persists a record, especially for the stubbed CRM handlers described earlier. Keep validation, runtime execution and business-record proof as separate checks.

End Workflow is the neutral ending alongside End (Success) and End (Failure). Choose the ending that describes the actual outcome; an ending label never proves a write or reverses earlier work. After changing an ending, inspect the completed run and its preceding side effects.

The Delete control on a Workflows card removes the entire automation, whereas a row Delete removes only that step from the edited definition. For a disposable definition, stop it, retain the test run/record IDs, then use the card’s Delete and its confirmation. Refresh Workflows and Schedule to check removal and cancellation of its future scheduled work. If you need the definition for comparison or diagnosis, leave it inactive instead. Deleting an automation does not undo messages already sent or business records already created.

Run Monitoring, Cancellation, Retry and Recovery

Local repair verified — 4 October: An earlier Wait/Delay → Create Task → End (Success) run created its task and then failed with Unknown step type: end. The local runner now handles terminal steps: regression tests and two real local API executions confirm success/failure endings stop later steps. The original combined wait exercise has not been replayed with its ending enabled, so its screenshots remain historical evidence. Always inspect the task output before retrying a failed run; an ending cannot undo an earlier write.

Before each manual test that creates a task, replace its Title with an unused fixed name, such as Cedar wait test 01 or Cedar retry test 01. Record that name and the returned ID. The handler uses Title as the unique Task name; an unchanged manual title, or an event variable with no manual event context, can fail independently of the wait/condition being tested. Increment the suffix only after inspecting whether the previous run already wrote its task. This does not make retries idempotent.

Current local run exec_1790992098498_45i55r completed its Create Task step and returned taskId 6ac05ee2412569923b11e662. The data it ran with is empty because Run once had no triggering record. This is run-output evidence; independent task-record readback is shown in the first-build chapter.

From Workflows open the inquiry workflow's name or monitor button. Choose Last 24 hours, 7, 14, 30 or 90 days to match the test. Read Runs, Success rate, last-run and duration measures with their window; a capped window or no completed runs limits what the figure means. Runs per day separates completed/failed runs. Happening now lists running or waiting executions. Errors groups failures by message, and Steps shows how often each step ran or failed.

Open Runs log, search a record name/email, error or execution ID and use the available status/step/time filters to isolate the test. Open one run. Read status, start/finish time and duration, then Why it failed, Step by step and The data it ran with. Open a step in the Steps table for its outcomes; inspect its inputs/outputs where supplied and follow the run link. A truncated success summary is not a full record readback: open the business record using its actual returned ID.

To test stopping a current execution, insert a one-minute wait in a disposable draft and Run once. While it is waiting, choose Stop run in the run drawer or Happening now, read Stop this run?, then confirm Stop run. Refresh and verify the canceled execution did not create the later task. The monitor's top-level Stop instead stops future trigger processing; it is distinct from cancellation of an existing run. Test those two controls separately.

For failure recovery, use a reproducible configuration fault on a disposable task action; the HTTP example remains blocked by the editor/handler JSON mismatch. Open the failed run, choose Fix this step in the builder →, correct the actual failing field and Save. Return to the failed run and choose Retry. Retry runs the workflow again with the original run's data; it is not necessarily a resume after the failed step. Before retrying, inspect whether earlier steps created a task, record or message so a second run does not produce an unnoticed duplicate. Capture the new execution ID and compare its output with the repaired action and business record.

If an active workflow reports a disconnected trigger, use Reconnect trigger and generate one fresh event after registration. If a log fails to load, use its retry control; empty results after a successful load are different from missing evidence. Finish the course exercise with the seed lead, event run and follow-up task matched by IDs, plus a stopped wait and a repaired failed run. Keep each provider or unavailable advanced branch pending until its own real demonstration exists.

A failed ending can leave a saved task

The local wait exercise illustrates why you must inspect individual steps before retrying. In Runs log, open the failed run. Under Step by step, Wait/Delay and Create Task have succeeded; end_success failed with Unknown step type: end.

Read the taskId from Create Task’s output. Open Database → Data Explorer → Task, find the title from that action and use the row’s Edit Raw JSON control. Compare sk and data.executionId with the run. Close with Cancel; checking a record does not require saving it.

Here, task 6ac1de0f7cbebaaf0dd3e210 exists with status pending and execution exec_1791090131884_0id4w3. This independently confirms the side effect. Retry would run against an already-created task, so it is not the next action for this error. Keep the workflow inactive, retain the error and run ID for support, and use the verified action-only first exercise to match these historical screenshots. The ending dispatcher has since been repaired and passed local API and regression checks; the original wait-plus-task replay remains pending.

The earlier cancellation test stopped a separate run during its wait. Its monitor showed stopped, zero live executions and zero executions of Create Task. Cancelling that run did not cancel the separate later run or undo that later run’s task.