Stay up to date on the latest product updates, customer stories, and industry news from Redpoint. Opt-in and select the topics you'd like to learn more about!
Redpoint Best Practices Documentation
Redpoint Best Practices Documentation
Breadcrumbs

Pausing and stopping interactions

Overview

Redpoint Interaction (RPI) provides the ability to pause or stop interactions to manage campaign workflows, perform maintenance, or address issues. Understanding the differences and downstream impacts of these actions is essential for maintaining system integrity and minimizing disruption.

Quick reference: pause vs. stop

Action

Retains state

Resumable

Temp tables persist

Use for

Pause

Yes

Yes

Yes — not time-limited while genuinely paused

Edits, short-term maintenance

Stop

No

No

No, dropped immediately

Permanent halt, major rework

Pausing an interaction

Pausing temporarily suspends workflow execution and audience progression.

  • What happens:

    • Workflows halt after their current step completes, and RPI holds audience members in place.

    • RPI stops processing new entries: it suspends triggers, schedules, and API (application programming interface) injections.

  • Typical use cases:

    • Mid-campaign adjustments

    • Short-term maintenance

    • Testing or validating configuration changes

    • Waiting for data loads

    • Delaying campaign delivery

  • Considerations:

    • Temp tables in RPI are ordinary database tables, not tables scoped to a database session; they are not affected by a session timing out or the RPI job service restarting. The audience/staging table for a paused workflow has no automatic time-based expiry while the workflow remains paused; it is only cleaned up once the workflow reaches a final state (stopped, completed, or expired). A separate, smaller set of workflow bookkeeping tables does auto-expire for a workflow left paused, on a 14-day timer (a configurable setting).

    • A workflow left paused indefinitely holds onto its audience/staging table indefinitely. Plan to stop (not just pause) anything you won't resume.

  • Additional resources:

Stopping an interaction

Stopping fully terminates workflow execution and clears all runtime states.

  • What happens:

    • All workflows end when the current activity completes. RPI performs no further audience processing.

    • RPI deletes temporary tables and session data right away.

    • To resume, restart the interaction from the beginning.

  • Typical use cases:

    • Decommissioning or retiring a campaign

    • Emergency stop due to data errors or logic failures

    • Complete reconfiguration or migration

  • Considerations:

    • The audience/staging table for a stopped (or completed) workflow is generally dropped immediately, not retained for a fixed window. A 7-day retention setting exists, but it applies to a separate family of audit/workflow bookkeeping tables, not the main audience data. If an immediate drop fails for any reason, a nightly housekeeping sweep catches the leftover audience table within 28 days.

    • If you need audience-level data after a stop, export or persist it to a permanent table beforehand. Don't rely on a retention window for the staging table.

  • Additional resources:

Rollbacks in RPI

Rollback refers to how RPI handles a failed step and any work it left behind. RPI does not wrap a step's database work in a transaction that gets rolled back on failure; writes commit as they happen. "Rollback" in RPI means that no uncommitted work is left behind (because there generally isn't any), and RPI restores its own internal tracking state for the failed step. It is not a database-style undo.

  • What happens:

    • If an activity encounters an error, RPI marks it as failed and will not advance audience members past the failing step unless the workflow is retried or restarted.

    • Because writes commit as they occur rather than being held open, there is no uncommitted database work to roll back in most cases. Earlier, already-committed steps are simply unaffected.

    • Rollback never retracts side effects already completed in external systems, such as files written, messages handed to an ESP (email service provider), or API calls to a CRM (customer relationship management) system. Those effects are outside RPI's control once sent.

    • Stopping a workflow does trigger a form of compensating cleanup: RPI deletes the offer-history/tracking records for the activity being stopped, including sub-steps that had already fully completed and sent, as part of stopping. This does not reach other, already-finished activities elsewhere in the workflow, and never touches external systems, but it is more than "only the in-flight transaction."

  • Typical use cases / scenarios:

    • Failed SQL step (constraint violation, timeout, permission issue).

    • Connection loss mid-step.

    • Stopping an interaction while a step is in-flight (that step's offer-history/tracking records may be cleaned up as part of the stop, but previously completed other steps remain untouched).

  • Considerations:

    • A failure or stop only affects the activity being stopped or failed and its own sub-steps. Earlier, separate steps in the workflow are never touched.

    • A later step's failure doesn't remove temp/staging tables from earlier, already-committed steps.

    • Pausing never triggers any rollback or cleanup; stopping does trigger cleanup of the stopped activity's own offer-history records, but this is bookkeeping cleanup, not a database rollback.

Temporary tables in RPI

  • Definition: RPI creates temporary (staging) tables during workflow execution to hold in-flight audience records, intermediate results, or step outputs.

  • Naming: These tables typically have generated names, using GUIDs (globally unique identifiers), workflow IDs, or instance IDs, and RPI scopes them to the workflow run.

  • Not session-scoped: These are ordinary persistent database tables, not database-session-scoped temp tables. They survive a database session timing out, a connection being recycled, or the RPI service restarting. They are removed only by explicit application cleanup (on stop/completion) or by the nightly housekeeping job.

When paused

  • Active queries stop once the current process step completes.

  • Persistence: The audience/staging table remains in place indefinitely while the workflow stays paused; it is not cleaned up on any timer as long as the workflow's status is Paused. It is only removed once the workflow is stopped, completed, or otherwise reaches a final state.

  • Risk: The main audience/staging table is not at risk from a service restart or session cleanup. A separate, smaller family of workflow bookkeeping temp tables does expire automatically for a paused workflow, on a 14-day timer; that is the actual time-based risk during a prolonged pause, not the audience table itself.

When stopped

  • Immediate cleanup:

    • All workflows and database sessions end.

    • RPI drops the audience/staging table immediately.

    • If cleanup fails, RPI removes the table during the next nightly maintenance cycle (within 28 days as a fallback ceiling).

Best practices

  • Do not rely on temp tables for long-term storage: Use permanent tables for any data that must persist through pauses or stops.

  • Don't treat "pause" as free of cleanup risk over the long term: The main audience table won't expire on its own while paused, but you should generally stop a workflow parked in Paused for weeks or months once you no longer need it. Leaving it paused indefinitely leaves that data in place indefinitely, too.

  • Check your environment's cleanup policies: Know the configured retention windows for workflow bookkeeping/audit temp tables in your RPI environment. The defaults are…

    • 14 days for a paused workflow's bookkeeping tables

    • 7 days for a stopped or completed workflow's audit tables, with a 28-day fallback sweep for anything an immediate drop missed

  • Use pause for short-term adjustments only: For major changes or error recovery, use stop.

  • Document reasons for pausing or stopping: RPI's audit log records who stopped a workflow and when, but it doesn't capture why. If you need a reason on record, document it outside RPI (ticket, email, runbook).

Scenario-based FAQs

Pausing interactions

  • What happens to in-flight audience records?
    Workflows halt at their current step, and RPI holds audience members in place. RPI processes no new entries, and in-flight records remain at their current workflow position.

  • Will paused workflows resume from the exact step?
    Yes. When you resume the workflow, it and its audience members continue from where they were paused.

  • Are scheduled triggers skipped during pause?
    Yes. RPI suspends triggers, schedules, and API injections during a pause, so scheduled triggers do not fire while paused.

  • Do temp tables persist if the pause exceeds session timeout?
    Yes. The audience/staging table is not session-scoped and is unaffected by a session timeout or a service restart; it persists for as long as the workflow stays paused. Only a separate, smaller family of workflow bookkeeping tables is time-limited during a pause (14 days by default).

  • Are outbound messages delayed or canceled?
    RPI delays outbound messages and doesn't send them while the workflow is paused.

  • What happens to channel activity steps (e.g., Send Email) that were about to execute?
    RPI holds any channel activity that was about to execute, such as Send Email, and resumes it when the workflow resumes.

  • Can channel suppression or deduplication states be affected?
    RPI is expected to preserve suppression and deduplication states during a pause, but verify against your environment's specific configuration if this is critical to a given campaign.

  • If a recurring workflow is paused, will it resume on the next scheduled interval?
    No. You must resume the workflow manually. It doesn't resume automatically on the next scheduled interval.

  • Are missed executions reprocessed or skipped after resumption?
    RPI skips missed scheduled executions rather than queuing or replaying them; only the current workflow state resumes.

  • Do file-based or API-based triggers queue up or are they discarded?
    RPI suspends triggers during a pause instead of queuing them, and it doesn't process new entries.

  • Will the workflow resume automatically or must it be resumed manually?
    You must resume it manually.

  • Are all activities and transitions preserved after resumption?
    Yes, RPI preserves all activities and transitions and continues them from the paused state.

  • Is there a risk of duplicated actions after a pause/resume cycle?
    Risk is low under normal conditions, since the audience/staging table itself isn't time-limited while paused. The main thing to watch is the smaller workflow bookkeeping tables' 14-day expiry during an unusually long pause. Check your environment's housekeeping configuration if a pause may run that long.

  • Are audit logs updated for traceability?
    Yes, RPI updates audit logs to reflect pausing and resumption actions, including who performed the action and when.

Stopping interactions

  • What happens to in-progress audience records?
    All workflows end when the current activity completes. RPI clears in-progress audience records, and no further processing occurs.

  • Are audience members mid-flow reprocessed or discarded?
    RPI discards them; stopping clears all runtime state.

  • Does stopping delete all runtime data immediately?
    Yes, RPI deletes temporary tables and session data right away.

  • Can the workflow be resumed from where it left off?
    No. To resume, restart the interaction from the beginning.

  • Is there a difference between stopping an interaction vs. a workflow activity?
    Yes. Stopping an interaction halts every workflow within it, while stopping a single workflow activity only halts that specific activity. Both are genuinely distinct operations in RPI.

  • Are temp tables dropped immediately?
    Yes. RPI drops the audience/staging table immediately upon stopping.

  • Is any data persisted to permanent tables before stopping?
    RPI retains only data explicitly written to permanent tables; it deletes the audience/staging table and in-memory data.

  • Could stopping mid-execution lead to orphaned temp tables or incomplete data sets?
    If immediate cleanup fails, the next nightly housekeeping sweep catches the table (within 28 days as a fallback) rather than leaving it behind permanently.

  • Does stopping impact staging data for downstream workflows?
    Yes. Stopping clears the workflow's own runtime state, which can impact downstream workflows that relied on that staging data.

  • What happens to audience members in the 'Playing' state?
    RPI terminates them and removes them from the workflow.

  • Are offer presentation or delivery steps canceled mid-execution?
    RPI cancels steps that hadn't yet started. A step that was already underway when you requested the stop is allowed to reach its next safe checkpoint, since RPI doesn't interrupt a send mid-call. Any work that step already completed is preserved, not lost.

  • Do stopped workflows update offer history or logs accurately?
    Yes for work completed before the stop. Stopping also actively deletes the offer-history/tracking records for the specific activity being stopped (including its own sub-steps that had already completed and sent) as part of the stop's cleanup; so "accurate" here means "accurate for what's retained," not "everything that happened is guaranteed to remain in offer history."

  • Will suppressed or deduplicated records be re-eligible after a stop?
    Suppressed or deduplicated records may become re-eligible if you restart the workflow from the beginning.

  • Is logging or event tracking preserved for auditing?
    Yes. RPI preserves activity- and status-level logging and event tracking for auditing purposes.

  • Are integrations (API calls, S3 exports, CRM writes) left incomplete?
    RPI terminates any in-progress integrations, and they may be left incomplete.

  • Does stopping trigger rollback for specific steps or systems?
    Not a database rollback, but stopping does trigger compensating cleanup: RPI deletes the offer-history/tracking records for the activity being stopped. It does not reach other, already-completed activities elsewhere in the workflow, and it never affects external systems.

  • Can the workflow be restarted cleanly?
    Yes, but it will start from the beginning, not from the stopped point.

  • Is reprocessing required for in-flight audiences at stop time?
    Yes. You must reprocess any in-flight audiences from the start, if needed.

  • Will rerunning result in duplicate actions or outputs?
    If you don't manage it carefully, rerunning could result in duplicate actions or outputs.

  • What checks should be done before restarting?
    Check for orphaned temp tables, incomplete data, and ensure all integrations are in a consistent state.

  • Is there an audit trail indicating who stopped the workflow and why?
    There is an audit trail showing who stopped the workflow and when. There is no mechanism to capture why; no reason/comment field exists for a stop action. If a reason needs to be documented, capture it outside RPI.

Rollbacks in RPI

  • Does pausing an interaction trigger a rollback?
    No. Pausing has no rollback or cleanup behavior of its own. If a step fails while RPI is processing a pause, RPI handles that failure the same way it handles any other failure (see below); pausing itself doesn't add anything.

  • Does stopping an interaction trigger a rollback?
    Not a database rollback — but stopping does trigger RPI to delete the offer-history/tracking records for the activity being stopped, including sub-steps that had already completed and sent. Work already committed by other, separate, already-completed activities in the workflow is not touched.

  • Are changes to external systems (ESP, S3, CRM, APIs) rolled back?
    No. Nothing in RPI retracts a file already written, a message already handed to an ESP, or an API call already made. Once sent, it's sent.

  • Can a rollback remove temp or staging tables created earlier in the run?
    No. Only the activity being stopped or failed is affected; temp/staging tables from earlier, separate, already-completed steps remain.

  • If I rerun or restart after a rollback, can I get duplicates?
    Yes, it's possible. If downstream systems already received data before the failure or stop, rerunning from the beginning can resend or recreate that data unless you have idempotency controls (keys or deduplication logic) in place.

  • Do rollbacks show up in logs or audit trails?
    Yes. RPI logs failed steps and stop actions, including which activity was involved, the error (if any), and the resulting status. It doesn't itemize individual row-level cleanup operations in those logs.

Additional resources