# Monitoring a flow How to see who entered a flow, follow one contact's journey step by step, and find out why a contact didn't enter or didn't receive a message. **Language:** en **Audience:** platform **TLDR:** Open Activity from the flow header: Entered lists each run with its status and version; Didn't enter lists dropped contacts with the reason (re-entry or concurrency limits, audience, trigger filter, exit event already received, plan or balance limits). Events that arrive while enrollment is paused or with an old date leave no trace. View detail opens the contact journey: every step, its status and why a message wasn't sent. **Translation key:** platform.automations.flows.monitoring-a-flow **Search keywords:** who entered, drop reason, dropped contact, why not enrolled, contact not enrolled, contact timeline, execution log, run history, not sent reason, why didn't the SMS arrive, stopped, canceled, advance, skip wait, inside now, people in the flow, troubleshoot a flow, debug a flow **Related pages:** /platform/es/automations/flows/monitoring-a-flow, /platform/en/automations/flows, /platform/en/automations/flows/triggers-and-entry, /platform/en/automations/flows/sending-messages, /platform/en/automations/flows/goals-and-exits, /platform/en/automations/flows/managing-flows, /platform/en/automations/flows/flow-analytics, /platform/en/automations/flows/limits-and-safeguards **Docs index (every page):** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/llms.txt **This zone's index:** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/en/llms.txt **This page:** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/en/automations/flows/monitoring-a-flow/ (HTML) · https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/en/automations/flows/monitoring-a-flow.md (Markdown) **Other language (es):** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/es/automations/flows/monitoring-a-flow.md Once a flow is published, three questions come up again and again: did this contact enter, why didn't that one, and what happened to them once inside. The panel answers them with three tools that work on live data. The **canvas** of a published version shows how many people are inside right now and where they're waiting. The **Activity** sheet lists every run that started and every entry attempt that was dropped, each with its reason. And the **Contact journey** opens one run and shows it step by step: what each step did, when, and — when a message didn't go out — why. These tools are for following individual contacts and checking that the flow behaves as you expect. Totals, rates, conversions and revenue are covered in [Flow analytics](/platform/en/automations/flows/flow-analytics). ## Live counters on the canvas Open a published version of the flow — its **Live** tab, the live test's tab, or a version from **Archived versions** in the archive box — and the canvas shows live figures. The **Build** tab never shows them: it is the draft, and nobody runs through a draft. - **"N inside now"**, the pill at the top left of the canvas, counts the people who are inside this version right now, waiting somewhere in it. It updates on its own about once a minute and covers the version's whole life, with no time window. - **Waiting**, on a step, appears only while someone is sitting at that step — usually a wait — and counts those people at the moment you look, so it can change while you're looking at it. - **Entries**, on every step, counts the runs that have reached that step. These are runs, not people: a contact who entered the flow twice counts twice. The figures in the KPI row above the canvas are a snapshot calculated in the background, while **"N inside now"** is live. That is why the two can disagree for a while — for example, right after the first contacts enter, the KPI row can still show "—" while the pill already counts them. What each KPI means is explained in [Flow analytics](/platform/en/automations/flows/flow-analytics). When nobody is inside, the pill reads "0 inside now" and its ⓘ explains why that is often normal: contacts entering through the event trigger wait a short processing window (typically under a minute) before their run starts (somewhat longer when there is a lot of traffic), while test runs start straight away. How long that entry wait lasts depends on the trigger's processing mode; see [The trigger: who enters and when](/platform/en/automations/flows/triggers-and-entry). Each version counts only its own contacts. After you publish a new version, the people who entered on the previous one finish on it, so the old version keeps a "N inside now" of its own until they're done; in the **Archived versions** list each version shows how many contacts are still inside it. While someone is inside, a ⊘ button next to the pill, **Cancel executions**, stops every run of that version; what it does and when to use it is in [Managing flows](/platform/en/automations/flows/managing-flows). ## Activity: who entered The **Activity** sheet opens from the button with a pulse icon in the flow header (tooltip **Recent activity**). The button appears once the flow has been published at least once — a flow that has only ever been a draft has no activity to show. When contacts have entered since you last opened it, the button shows a blue badge with their number ("9+" beyond nine), and its tooltip reads, for example, "3 contacts entered recently. Open the activity". The sheet is titled **Activity** — "Who entered, and why some contacts didn't." — and has two views, switched at the top right: **Entered** (the default) and **Didn't enter**. It covers all the flow's versions at once and refreshes on its own every few seconds while it is open, so you can leave it open while you test. Its table can be exported. **Entered** lists one row per run, with these columns: | Column | What it shows | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Contact** | The contact's name. | | **Status** | Where the run stands (see the table below). | | **Version** | The version the contact entered on — **v1**, **v2**… — or **Preview** for a test run. Contacts who entered before you published a new version keep their old number: they finish on that version. | | **Started** | When the contact entered. | | **Completed** | When the run ended; empty while it's still going. | | **Entered via** | **Trigger** when the contact came in through the flow's trigger; **Test** when someone ran the flow for that contact from the test tool. | | **View detail** | Opens the contact journey for that run. | A run's status tells you how it ended, or that it's still going: | Status | What it means | | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Pending** | The contact has qualified and the run is about to start. | | **Running** | The contact is inside the flow, on a step or waiting in one. | | **Completed** | The contact reached the end of their path through the flow. | | **Goal met** | The run reached the flow's goal, after at least one message had been sent to the contact. This label replaces the others whenever the goal is reached. | | **Goal without a send** | The contact met the goal before the flow had sent them anything — for example, they bought before the first reminder. This is correct behaviour, not a failure. | | **Stopped** | The run stopped at a step that couldn't do its job: most often a message that couldn't be sent while **Stop the run if the message can't be sent** was on. | | **Canceled** | The run was ended on purpose: an exit event arrived, someone cancelled it by hand, or the contact left the audience while **Cancel the run if the contact leaves the audience** was on. | | **Failed** | The run couldn't continue because of an error in the flow or in the platform. The journey shows the reason. | When the goal counts, and why a purchase can count as the goal without a click, is explained in [Goals and exits](/platform/en/automations/flows/goals-and-exits). ![The Activity sheet listing runs with their status and version](/platform/en/automations/flows/images/monitoring-a-flow--1-activity.png) ### Find one contact The search box at the top of the sheet, "Search a contact by name, email or phone", answers "where is this person?" without scrolling. Type at least three characters and select the contact; the table is replaced by what the flow knows about them, in three groups: - **In this flow** — all their runs of this flow, finished ones included. - **Active in other flows** — runs still in progress in other flows of the project, so you can see whether two flows are messaging the same person. - **Recent drops in this flow** — their dropped entry attempts, with the reason, so you can see why someone didn't enter. If there is nothing to show, the panel says "This contact has no active execution and no recent drop in this flow." **Back** returns to the full table. The Activity is a working view of recent runs, not a permanent archive: the details of finished runs are removed after a while, although they still count in the flow's figures. For an older send, search the contact's mobile number in **Message history**, on the **Audience** tab of the [flow report](/platform/en/automations/flows/flow-analytics#audience), with a period that covers the date: it outlasts the Activity detail. ## Why a contact didn't enter Every time a contact's event qualifies for the flow, the flow checks whether the contact can enter at that moment: the audience, the trigger's event conditions, the re-entry limits, the **Enrollment pace** settings and your plan's ceilings. A contact who fails a check is **dropped** — they don't enter this time, nothing is queued, and their next qualifying event is a new attempt. The settings behind each check are explained in [The trigger: who enters and when](/platform/en/automations/flows/triggers-and-entry). The **Didn't enter** view lists those dropped attempts, one row per attempt, with the columns **Contact**, **Reason**, **Attempt** (when the entry was evaluated) and **Version**. When there's nothing to show: "No drops recorded — When contacts enter or are dropped, they'll show up here." These are all the reasons the panel can show, and what to do about each: | Reason | What it means | What you can do | | -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Per-contact frequency limit reached** | The contact had already entered this flow less than the **Minimum time between enrollments** ago. The time counts from the start of their last entry; a dropped attempt doesn't restart it. A [test run](/platform/en/automations/flows/versions-and-publishing#what-a-test-run-checks-and-what-it-doesnt) with this contact counts as an entry while its run is kept (14 days). | Nothing, if that's the spacing you want. To let contacts re-enter sooner, lower the minimum in the trigger's **Limits** tab (it can go down to 1 minute). | | **Per-contact concurrent-flows limit reached** | Despite the wording, this is about runs of **this** flow, not other flows: the contact already had as many runs of this flow in progress, across all its versions, as **Simultaneous runs per contact** allows. Only runs of this flow count, never runs of different flows. While its run is kept (14 days), a [test run](/platform/en/automations/flows/versions-and-publishing#what-a-test-run-checks-and-what-it-doesnt) of this flow still in progress for the contact does. | Raise **Simultaneous runs per contact** (up to 10), or leave it if one run at a time is what you want. | | **Per-contact re-entry limit reached** | The contact has used up the **Enrollments per contact limit** — for example, **Once only** and they had already entered. It counts the contact's entries in every version, including runs that were later cancelled, with no time limit, so a contact on **Once only** never enters again. A [test run](/platform/en/automations/flows/versions-and-publishing#what-a-test-run-checks-and-what-it-doesnt) with this contact counts as an entry too, but only while its run is kept (14 days). | Change the limit to **No limit** and control the frequency with **Minimum time between enrollments**. | | **Hourly entry cap reached** | The flow reached the hourly limit you set under **Enrollment pace** (**Enroll up to** *N* **contacts per hour**). | Raise it in [Enrollment pace](/platform/en/automations/flows/triggers-and-entry#enrollment-pace), if the volume is expected. | | **Daily entry limit reached** | The flow reached the daily limit you set under **Enrollment pace** (**Enroll up to** *N* **contacts per day**). | Raise it in [Enrollment pace](/platform/en/automations/flows/triggers-and-entry#enrollment-pace), if the volume is expected. | | **Project hourly limit reached (plan limit)** | Your plan's hourly entry ceiling was reached. That ceiling is shared by all the flows of the project, so a busy flow can use it up for the others. | See [Limits and safeguards](/platform/en/automations/flows/limits-and-safeguards). | | **Hourly entry limit reached: the account has no funds** | The account ran out of balance, so entry into the flow dropped to a trickle. | Add funds and turn on [auto-reload](/platform/en/billing/wallet-balance#auto-reload); see [Limits and safeguards](/platform/en/automations/flows/limits-and-safeguards). | | **The contact is in an excluded segment** | The contact didn't match the flow's audience when the event arrived. Despite the wording, it also appears when the contact simply isn't in the segment selected under **Include**, not only when they are in an excluded one. | Check the audience in the trigger's **Trigger** tab: the segment under **Include**, and the ones under **Exclude segments**. | | **The event didn't match the trigger's filter** | The event didn't meet the conditions you added to the trigger event. | Select **See what the filter asked for** (below). | | **The exit event arrived before the contact entered** | The contact had already done one of the flow's exit events, so they never entered — for example, they bought within moments of starting a checkout. The row is shown muted, with a check: this is the flow working as intended. | Nothing. See [Goals and exits](/platform/en/automations/flows/goals-and-exits). | | **Already has an execution for this event** | The same event reached the flow twice. One event never creates two runs. | Nothing. | | **Another activation for this contact was in progress** | Two qualifying events of the same contact arrived almost at the same moment, and only the first one was evaluated. That first one may or may not have entered — check **Entered**. This attempt isn't retried. | Usually nothing. If your data source sends the same action twice in quick succession, consider sending it once. | | **Contact not ready to evaluate yet** | The flow couldn't check the contact against the audience at that moment — usually because the contact had just been created or updated and their data wasn't ready yet. The flow re-checks such contacts by itself for a while before giving up, so by the time this row appears the attempt is final. | The contact can enter on their next qualifying event. If it happens a lot, contact support. | | **Doesn't meet the flow's entry conditions** | At the moment of the check, the flow wasn't taking entries on that version — for example, enrollment had just been paused or a new version had just replaced it — or the contact no longer existed. | Check that enrollment is active and that the version you expect is **Live**. | | **Dropped by the project's load protection** | Too many entries arrived across the project in a very short time, and the protection dropped some of them. The rows are a sample, not one per dropped contact. | Spread out large imports or bursts of events; see [Limits and safeguards](/platform/en/automations/flows/limits-and-safeguards). | | **Project locked (billing/suspension)** | The project is locked, so no flow in it can take entries. | Review the account's billing, or contact support. | | **Not allowed** | The project couldn't start runs of this flow at that moment. | Contact support if it persists. | | **Unknown reason** | The panel doesn't recognise the reason. | Contact support. | **See what the filter asked for.** A row dropped by the trigger's filter has this link. It opens **The trigger's filter**: "The event had to match every condition below. What the event itself carried isn't stored." The conditions the event failed are marked **Didn't match**, so you can tell which one stopped the contact even though the event's own values aren't kept. When the filter asks for new contacts, the sheet also notes that the filter passes if the contact was created only a short time before. Long filters are shown abbreviated. Drops are kept only for a short time: the **Didn't enter** view is for recent attempts. When a customer asks why someone didn't enter, look the same day. ![The Didn't enter list with the reason each contact was dropped](/platform/en/automations/flows/images/monitoring-a-flow--3-didnt-enter.png) ### What leaves no trace Some events never reach the checks above, so they appear in neither **Entered** nor **Didn't enter**: - events that arrive while **enrollment is paused** (the same as disabling the flow from the list) or after the flow has been archived; - events with an **old date** — historical events don't start flows; - events loaded by a data source's **initial sync** or by a **CSV import**; - events of a type, or from a data source, that can't start a flow, and events from a different data source than the one selected in the trigger. Which events can start a flow, and which never do, is listed in [The trigger: who enters and when](/platform/en/automations/flows/triggers-and-entry) and [Limits and safeguards](/platform/en/automations/flows/limits-and-safeguards). #### A contact did the trigger event but isn't in the flow. Where do I look? Open **Activity** and search for the contact. If they appear under **In this flow**, they did enter: open the run to see where they are. If they appear under **Recent drops in this flow**, the reason says what stopped them — "The contact is in an excluded segment" usually means they aren't in the segment under **Include**. If there's no run and no drop, the event didn't reach the flow's checks: check that enrollment was active at that moment, that the event wasn't an old or imported one, and that it came from the data source selected in the trigger (or that the trigger uses **Any data source**). #### The contact did the event three times and only entered once The re-entry limits are doing their job. Take a flow on **Checkout started** with **Minimum time between enrollments** at 1 minute, **Simultaneous runs per contact** at 1, and a 2-minute **Fixed delay** before its message. Laura starts a checkout at 10:00:00, 10:00:10 and 10:01:15. The first event enters. The second, ten seconds later, is dropped with "Per-contact frequency limit reached": less than a minute has passed. The third comes after the minute, but Laura's first run is still waiting in the delay, so it's dropped with "Per-contact concurrent-flows limit reached". Laura has one run, and **Didn't enter** shows the two drops with their reasons. #### I can't see the Recent activity button It appears once the flow has been published at least once. A flow that has only ever been a draft has no runs to show; to try a draft, use a test run (see [Testing, publishing and versions](/platform/en/automations/flows/versions-and-publishing)). ## The contact journey **View detail** on a row of **Entered**, or a run in the search results, opens the **Contact journey**: "Step-by-step of this execution, with status and timing." It is the place to answer "what happened to this person in this flow?" — which steps they went through, how long they waited, which message they were sent and, if something went wrong, why. The header shows the contact and the run's status. Below it, a summary: - **Started** and **Ended** — when the run started and ended. - **Version** — the version the contact is running on. - **Execution ID** — the run's identifier. Give it to support if you ask about a specific run. - **Waited in total** — the time the contact has spent in waits so far. - **Last send** — the channel of the last message and when it went out. When an RCS message fell back to SMS, it shows both, as "RCS → SMS". **Execution context**, collapsed by default, records how the run started: **Triggered at** (when the trigger event happened), **Entry timing** and **Entry offset** (how long the contact waited between the event and the start of the run). **Entry timing** takes one of these values: - **Processing window** — the usual case: the contact waited out the short processing window (typically under a minute) before entering so that the flow decides with up-to-date data. - **Grouped by high demand** — the flow was receiving many entries at once, so entry was held somewhat longer. This never delays a message beyond the waits that come before the first send. - **Instant processing** — the flow uses the **Instant** processing mode and the contact entered straight away. - **Manual run** — a test run started by hand. The modes themselves are explained in [The trigger: who enters and when](/platform/en/automations/flows/triggers-and-entry). Then comes **one row per step** the contact has reached, in order: the step's name, the time, a status badge and, when there's something to explain, a reason line. Steps the contact hasn't reached yet aren't listed; a run that hasn't recorded any step yet shows "No steps recorded yet". | Step status | What it means | | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Pending** | The step is about to run. | | **In progress** | The step is running now. | | **In branch** | A split step: the contact is going through one of its branches. | | **Waiting** | A wait is holding the contact. The line underneath says when it ends, for example "Waiting · fires in 20 hours". | | **Completed** | The step did its job. On a Send message step, it means the message was sent — not necessarily delivered. | | **Not sent** | A Send message step couldn't send its message, and the run carried on because **Stop the run if the message can't be sent** was off. The reason line says why. | | **Skipped** | The step was passed over without acting; the reason line says why. | | **Stopped** | The run stopped at this step. The reason line says why. | | **Failed** | The step failed with an error. | | **Canceled** | The run was cancelled while the contact was at this step — by an exit event, by hand or because they left the audience — or the step was still open when the run ended. | On a Send message step that sent its message, **View message** opens the message that went out, with its details — including the consent policy it was sent with and the real short link of that send, which the canvas preview doesn't show. Two limitations to keep in mind. The journey doesn't name the branch a contact took after a split: work it out from the next step in the list, or from the message they were sent (**View message**), and give your branches clear names so it's easy to read (see [Branches](/platform/en/automations/flows/branches)). And some technical detail lines under a reason may appear in English. Test runs add two lines of their own: a note when a branch was forced by the test ("Forced through…") and "Wait skipped for this test" when a wait was skipped; see [Testing, publishing and versions](/platform/en/automations/flows/versions-and-publishing). ![The contact journey of one run, step by step with each status](/platform/en/automations/flows/images/monitoring-a-flow--2-contact-journey.png) **Example.** A shop runs an *Abandoned cart* flow: on **Checkout started**, a **Smart delay** picks a good moment, an SMS reminds the shopper, and a **Wait for activity** gives them a day to tap the link before a second SMS with a discount. **Order created** is the exit event and the flow's goal. Support is asked whether Marcos got the reminder. In **Activity**, his row reads **Running**, **v1**, **Trigger**. His journey shows the smart delay **Completed**, the SMS **Completed** — **View message** shows the text that was sent — and the wait for activity **Waiting · fires in 20 hours**. An hour later Marcos buys: the run ends at once, the wait shows **Canceled** with "The contact left through one of the flow's exits.", the second SMS is never sent, and his row in **Activity** turns to **Goal met**. ### Why a message wasn't sent When a Send message step couldn't send its message, its row shows one of these reasons (the run then shows **Stopped**, or the step shows **Not sent** if the run carried on): | Reason | What it means | | ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Not sent: the contact doesn't meet the channel's consent policy** | The message's consent policy excludes this contact — for example, the message is set to **Opt-in** and the contact never accepted marketing. See [Sending messages](/platform/en/automations/flows/sending-messages) and [Compliance policies](/platform/en/campaigns/compliance-policies). | | **Not sent: the contact isn't reachable on this channel** | The contact can't receive this channel — for example, they have no mobile number, or for RCS their phone is known not to support it. | | **Not sent: no channel could deliver to this contact** | None of the message's channels — the RCS message and its SMS fallback — could reach the contact. | | **Not sent: the message isn't fully configured** | Something the message needs is missing for this contact — for example, there's no text in the contact's language and no default text. | | **Not sent: the sender isn't available for this destination** | The selected sender can't send to the contact's country. See [Countries & regulation](/platform/en/channels/countries). | | **Not sent: blocked by a country regulation** | A rule of the contact's country blocked the message. See [Countries & regulation](/platform/en/channels/countries). | | **Not sent: the delivery attempt failed** | The message was ready, but handing it over for delivery failed. | | **Not sent: the run had no contact to send to** | The contact no longer existed when the step ran — for example, it had been deleted. | | **The message was not sent.** | A generic version, when no more specific reason was recorded. | When an RCS message fell back to SMS, the step also explains it: "Sent on SMS. The channels before it couldn't deliver to this contact:", followed by the reason the RCS level was passed over. A **Completed** Send message step means the message was sent, not that it was delivered or read. To check whether it was delivered, open the **Audience** tab of the [flow report](/platform/en/automations/flows/flow-analytics#audience): **Message history** lists each message with its status, and you can search it by mobile number. To act on delivery inside the flow, add a **Wait for delivery** after the message (see [Waits](/platform/en/automations/flows/waits)). The flow's messages also appear in the contact's own [Activity](/platform/en/audience/contacts-profiles#activity) timeline, linked to the flow. ### Why a run ended When a run ends for any reason other than reaching the end of its path, the journey shows the reason on the step where it happened: | Reason | Run status | What it means | | --------------------------------------------------------------- | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | **The contact left through one of the flow's exits.** | Canceled (or **Goal met**) | One of the flow's exit events arrived while the contact was inside. See [Goals and exits](/platform/en/automations/flows/goals-and-exits). | | **The run was ended manually.** | Canceled | Someone cancelled this run, or all the runs of its version with **Cancel executions**. | | **The contact left the required audience or segment.** | Canceled | The contact stopped matching the flow's audience, and **Cancel the run if the contact leaves the audience** was on. | | **This flow version was retired; the contact's run was ended.** | Canceled | The version the contact was running on had been archived for about three months (counted from the day it was archived), and the run was closed. | | **The step could not send the message.** | Stopped | The message couldn't be sent and **Stop the run if the message can't be sent** was on. The line below gives the specific reason, from the table above. | | **No branch matched, not even the default one.** | Failed | A split couldn't route the contact. It shouldn't happen, because every split has a default branch; contact support with the **Execution ID**. | | **The run stopped due to an internal issue (code N).** | Stopped or Failed | Something went wrong on our side. Contact support with the **Execution ID**. | A step can also show **Canceled** with "The flow ended before this step finished." That isn't an error: the step was still open — a wait, for example — when the run ended for another reason, such as an exit event. ## Act on one run If you can edit the flow, the contact journey of a run that is still in progress offers two actions, just below the summary. **Advance** appears when the contact is held in a wait. It releases the wait now, as if its time had run out: a timed wait finishes, and a wait that listens for something — **Wait for activity**, **Wait for delivery** — takes the path it takes when its time runs out, such as **No interaction**; a **Wait for delivery** with no final delivery status yet resolves as **Not delivered**. The contact then carries on through the flow straight away, and any messages after the wait are sent and charged for real. The panel confirms with "Advancing the execution", or says "Nothing to advance right now" if the contact is no longer waiting. It's most useful while testing a flow, but it works on any run in progress, not only test runs. **Cancel execution** stops this one run: "The contact stops here and won't continue the flow. This can't be undone." The run ends **Canceled**, with "The run was ended manually." on the step where it stopped, and none of the later steps run. Other runs, including other runs of the same contact, are not affected. To stop every run of a version at once, or to understand what cancelling does to a message already on its way, see [Managing flows](/platform/en/automations/flows/managing-flows). ## Related - [The trigger: who enters and when](/platform/en/automations/flows/triggers-and-entry) - The audience, re-entry limits and Enrollment pace settings behind each drop reason. - [Goals and exits](/platform/en/automations/flows/goals-and-exits) - When a run counts as Goal met, and how exit events end it. - [Managing flows](/platform/en/automations/flows/managing-flows) - Pausing enrollment and cancelling the runs of a version. - [Flow analytics](/platform/en/automations/flows/flow-analytics) - Activations, contacted runs, goal rate, conversions and cost. --- This is one page of the Instasent documentation. For the complete machine-readable index of every guide and API reference, fetch https://staging-instasent-docs-nextjs.oscar-284.workers.dev/llms.txt — start there for full context.