Automation
Automate Call Analysis with Make
A practical guide to building automated transcript analysis pipelines in Make (formerly Integromat). Use HTTP modules, JSON parsing, Routers, and Iterators to send transcripts to the Semarize API, extract structured scores and signals, and route results to your CRM, Slack, or database.
What you'll learn
- How the Webhook → HTTP Module → JSON Parse → Router pattern works in Make Scenarios
- How to configure the HTTP module to call the Semarize /v1/runs endpoint in sync mode
- How to use Routers for conditional branching based on brick values like risk flags and scores
- Five ready-to-use Scenario templates — CRM scoring with Router branching, Slack risk alerts, batch processing with Iterators, multi-Kit evaluation, and compliance monitoring with error handling
- Advanced patterns: error handler routes, Iterator/Aggregator for batch processing, data stores for deduplication, and scheduled polling
Context
Why Make for Automated Call Analysis
Make (formerly Integromat) offers a visual, module-based automation builder with native support for conditional branching, batch processing, and per-module error handling. It's the strongest choice when your workflow needs more than a linear pipeline.
Make strengths
Consider alternatives when
Make is the best choice when your call analysis workflow involves branching logic (risk alert and CRM update from the same analysis), batch processing (analysing a list of calls from a CSV or API response), or when you need granular error handling per step. The visual builder makes complex Scenarios easier to reason about than equivalent multi-path setups in other platforms.
Architecture
How Make + Semarize Works
Every Make Scenario with Semarize follows a four-stage pattern: a trigger receives or fetches transcript data, the HTTP module sends it to the Semarize API, the JSON module parses the structured response, and a Router branches the results to different destinations based on brick values.
1. Trigger
What starts the Scenario. A custom webhook receiving a POST, or a scheduled module polling your call platform for new recordings.
Webhook, Gong, Google Drive, HTTP Poll
2. Analyse
The HTTP module sends the transcript to the Semarize API in sync mode. The response returns inline with structured scores and signals.
HTTP - Make a request, POST /v1/runs
3. Parse
The JSON module parses the response body into mapped fields. Brick values become accessible as variables in downstream modules.
JSON - Parse JSON, data structure mapping
4. Route
A Router splits the flow into conditional branches. Each branch can filter on brick values and route to different destination modules.
Router, Salesforce, Slack, Sheets, DB
Sync vs. async mode in Make
Use mode: "sync" for simple Scenarios - the HTTP module waits for the response and you can parse results immediately. Make's HTTP module supports up to 40 seconds of wait time, which is sufficient for most transcripts. For very long calls or batch processing where you want non-blocking execution, use async mode with a polling loop (Repeater + HTTP + Sleep modules) or configure a Semarize workspace webhook to trigger a separate Scenario on completion.
Setup Guide
Build Your First Scenario: Step-by-Step
This walkthrough builds a complete Scenario: webhook trigger, Semarize API call, JSON parsing, Router with conditional branches, and destination modules.
Create a new Scenario and add the trigger module
In Make, click Create a new scenario. Add your first module - the trigger. For most setups, use a Custom Webhook.
transcript field (text) and optionally call_id (text). Make generates a unique webhook URL you'll POST to from your source system.Add the HTTP module to call the Semarize API
Click the + button after your trigger module. Search for HTTP and select Make a request.
Module configuration
Request body (Raw JSON)
{{1.transcript}} references the transcript field from Module 1 (webhook).Add the JSON Parse module
Add a JSON - Parse JSON module after the HTTP module. This converts the raw response into structured fields you can reference in downstream modules.
Module settings
Tip: auto-generate data structure
Click "Add data structure" then "Generator". Paste a sample Semarize JSON response and Make will create the field mapping automatically. This saves time and avoids manual structure definition errors.
Add a Router for conditional branching
Add a Router module. This splits the flow into parallel branches. Each branch can have a filter condition based on parsed brick values.
Branch 1 - Risk alert
3.output.bricks.risk_flag.value = true
Slack - Send Message to #deal-alerts
Branch 2 - All deals (fallthrough)
No filter (always executes)
Salesforce - Update Opportunity
Configure destination modules on each branch
Add a destination module at the end of each Router branch. Map brick values from the JSON Parse output to the appropriate fields in each destination.
Salesforce - Update a Record
AI_Score__c, Risk_Flag__c, Pain_Point__c
Slack - Create a Message
Channel, text with score, risk reason
Google Sheets - Add a Row
call_id, date, score, risk, pain_point
Airtable - Create a Record
All brick values as field mappings
Test each module and activate the Scenario
Use Make's Run once button to test the entire Scenario. Send a sample payload to your webhook and verify each module:
Once all modules pass, set the Scenario scheduling (immediate via webhook, or a polling interval) and toggle the Scenario to Active.
API Reference
API Request & Response Details
A deeper look at what the HTTP module sends and what Semarize returns. These are the exact values you'll configure in your Make Scenario.
Request
Response (200)
Brick value types
| Type | Example brick | Example value | Make field mapping |
|---|---|---|---|
| Numeric (score) | overall_score | 72 | Number → map directly |
| Boolean (flag) | risk_flag | false | Boolean → Router filter |
| Text (extraction) | pain_point | "Losing 3 hrs/week..." | Text → map to string field |
| Categorical | call_stage | "discovery" | Text → Router filter / map |
202 with sync_fallback: true and a run_id. In Make, handle this by adding a Router after the HTTP module: one branch for status = "succeeded" (normal path) and another for sync_fallback = true (poll with a Repeater + Sleep + HTTP GET loop).Templates
Scenario Templates for Common Use Cases
Five ready-to-use Scenario patterns that leverage Make's unique strengths - Routers, Iterators, and error handling routes. Each template shows the complete module chain with configuration details.
Discovery Scoring to Salesforce with Risk Router
Router sends risk alerts to Slack AND updates the CRM on every call
Bricks used
The Router splits results into two paths: risk-flagged calls trigger a Slack alert (Branch 1), while all calls update the Salesforce Opportunity (Branch 2, fallthrough). Both branches execute in parallel when a call is flagged.
Filter: risk_flag.value = true
Slack - Send Message
#deal-alerts: Risk flagged
Filter: none (fallthrough)
Salesforce - Update Record
AI Score, Pain Point, Next Steps
Both branches execute in parallel when risk_flag is true
Deal Risk Alerts to Slack
Router filter ensures only flagged calls generate alerts
Bricks used
A single-branch Router with a filter: only continue when risk_flag.value = true. The Slack module formats a rich message with the risk reason, score, and rep name. Non-risk calls are silently dropped - no noise.
Updated by Make Scenario · 8 seconds ago
Batch Processing to Google Sheets
Iterator processes an array of calls and writes each result as a row
Bricks used
A scheduled trigger fetches a list of new calls. The Iterator module splits the array into individual items. Each iteration sends one transcript to Semarize, parses the result, and appends a row to Google Sheets. This is Make's native approach to batch processing - no workarounds needed.
Multi-Kit Evaluation (Score + Coach)
Two HTTP modules in sequence - scores to CRM, coaching to Slack
Two Kits in one Scenario
Chain two HTTP modules, each calling the Semarize API with a different kit_code. Kit 1 scores discovery quality, Kit 2 extracts coaching signals. Use a Router after each JSON Parse module to send scores to Salesforce and coaching feedback to a Slack DM. Make's visual canvas makes this parallel-output pattern easy to build and debug.
→ Salesforce Opportunity
→ Slack DM to rep
Compliance Monitoring with Error Handling
Error handler routes ensure no call slips through unchecked
Bricks used
For regulated industries. Every call is checked against a compliance Kit. An error handler route on the HTTP module catches API failures and queues them for retry - ensuring no call is missed. Violations route to a compliance database; clean calls are logged silently.
4 of 5 checks passed · Flagged for review
Error handler → retry queueAdvanced
Advanced Make Patterns
Beyond the basic Scenario - patterns that leverage Make's unique capabilities for error resilience, batch processing, data aggregation, and deduplication.
Error handling routes
Make lets you attach an error handler route to any module. When the module fails (e.g., HTTP 429 rate limit, 500 server error), execution branches to the error handler instead of halting the Scenario.
Retry
Re-execute the failed module after a configurable delay. Best for transient failures (429, 503).
Break
Move the failed bundle to the Incomplete Executions queue. Process it manually or let Make auto-retry later.
Ignore
Silently skip the error and continue execution. Use for non-critical modules where failure is acceptable.
Rollback
Mark the entire Scenario execution as failed and roll back any committed operations. Use for all-or-nothing workflows.
Iterator + Aggregator for batch processing
The Iterator splits an array into individual bundles. After processing each item through Semarize, the Aggregator collects all results back into a single array. This is ideal for generating summary reports.
Example: Weekly call summary
The Aggregator collects scores, counts risk flags, and computes averages - then writes a single summary row.
Data Store for deduplication
Use Make's built-in Data Store to track which calls have already been processed. Before calling the Semarize API, check the Data Store for the call ID. If it exists, skip the call. If not, process it and add the ID afterward.
Scheduled polling with async mode
For very long transcripts where sync mode might timeout, use async mode with a polling pattern. Submit the run with mode: "async", then use a Repeater module with a Sleep delay to poll GET /v1/runs/:runId until status is "succeeded". Alternatively, configure a Semarize workspace webhook to trigger a separate Make Scenario when the run completes - eliminating polling entirely.
Reverse pattern: Semarize webhook → Make
Instead of calling Semarize from Make, trigger Scenarios from Semarize. Configure a workspace webhook in Semarize to POST to a Make Custom Webhook URL when runs complete. This approach is useful when runs are started from your backend or the Semarize app, and you want Make to handle downstream routing.
run.completed event. Make will receive the full run output as the trigger data.Watch out for
Common Challenges & Gotchas
These are the issues that come up most often when teams build call analysis Scenarios in Make.
Operations-based pricing adds up fast
Every module execution counts as one operation. A 5-module Scenario processing 100 calls/day uses 500 operations/day. Map out your module count per Scenario before committing to a Make plan.
JSON parsing requires explicit data structures
Make's JSON Parse module needs a pre-defined data structure. You must create the structure manually (or use "Determine data structure" with a sample response) before brick values are accessible in downstream modules.
Router filter syntax is strict
Router filters use Make's expression syntax, not JavaScript. Comparing nested values like bricks.risk_flag.value requires navigating the parsed JSON structure step by step. Test filters with the DevTool before activating.
Webhook vs. scheduled trigger tradeoffs
Webhooks fire instantly but require your source system to POST. Scheduled triggers poll at intervals (minimum 1 minute on paid plans, 15 minutes on free). Choose based on your latency requirements.
HTTP module timeout is 40 seconds by default
Make's HTTP module times out after 40 seconds. Semarize sync mode typically completes in 1-5 seconds, but very long transcripts or complex Kits may approach this limit. Use async mode with a polling loop for safety on long calls.
Iterator output is sequential, not parallel
The Iterator module processes array items one at a time, not in parallel. For 50 calls, this means 50 sequential HTTP requests. Factor this into your Scenario execution time budget.
Error handler routes don't retry by default
Attaching an error handler to a module catches the error but doesn't retry automatically. You need to explicitly add a "Retry" directive or use the Break directive to move the bundle to the incomplete executions queue.
Data store operations count toward your plan
If you use Make's built-in Data Store for deduplication or caching, each read/write counts as an operation. For high-volume deduplication, consider an external database instead.
FAQ
Frequently Asked Questions
Explore