--- title: Outbound Call Context Policies slug: contact-center/outbound-call-context-policies docTags: createdAt: 2026-04-18T18:58:14.337Z --- # Overview **Outbound call context policies** control how the platform **chooses a customer call context** (voice path and related resources) for each outbound dial attempt—for example progressive or preview dialing, manual dial, or flows that originate a customer leg from a campaign. Administrators and flow designers pick a **policy type** and related campaign or failover settings so that each call uses an **available** context within limits, follows **priority** when you want primary then secondary paths, or follows **round-robin** rules when several contexts are valid. # How It Works 1. **Choose the policy for the campaign (or dial profile)** In voice campaign configuration, you assign an **outbound call context determination** policy. The platform loads that policy when a dial is placed unless a **named policy** is supplied for that specific dial (advanced or integration scenarios). 2. **Policy evaluates candidates** For each dial, the policy considers configured call contexts, **availability**, **utilization limits**, optional **voice resource** constraints, and—where applicable—**destination number** patterns. It picks one context for the customer leg or marks the attempt failed if nothing qualifies. 3. **Automatic retry inside one dial step** Only the **Multiple try round robin** policy type enables an **automatic second originate** inside the same step when the customer leg fails **before ringing**. Other policy types—including **Failover**—do **not** perform that in-step automatic retry; the attempt may end in a dial-failed style outcome unless your **flow** triggers another dial. 4. **Customer Usecases ** - **Every new call:** Use **Failover** policy, put **primary** customer contexts at **priority 1** and **secondary** at **priority 2**, and complete **failover mapping** (campaign, voice resources, customer and agent contexts as required by your deployment). - **Same logical flow, try secondary after a failure:** Chain **two** originate or dial steps on the **same** flow instance: the first attempt uses Failover (usually primary); on the configured failure transition, the second step runs determination again so the temporary unavailable list can steer traffic to **secondary**—confirm in your environment that the list persists between those steps. **For Partners and Professional Services Team** 1. **Temporary “down” contexts on the same session** During **one** outbound session (same logical flow instance), contexts that already failed or timed out can be added to an internal **temporary unavailable** list. Later steps in **that same flow** skip those contexts so a follow-up dial can move to the next priority or the next round-robin choice. **Important:** That list is tied to the **current session**. A **new** outbound call starts with a **fresh** list, so a primary path can be tried again on the next call. 2. **Early dial failure vs no-answer** If the customer leg **fails before ringing** (for example setup or routing failure), the failed context is typically added to the temporary unavailable list **regardless** of other preferences. If the call **rings** and ends as **no answer**, whether the context is added to the temporary list depends on the `failoverNoAnswerTempDown` preference (see the note below the configuration table). ## Prerequisites - **Administrator** (or equivalent) access to **voice campaigns**, **call contexts**, and **voice resources**. - **Failover** setups require failover relationships and mappings to be defined consistently with your voice architecture (including any constraints such as contexts on the **same** call server where the product requires it). - For **advanced flows**, a **node flow** (or integration) that can branch on dial failure or no-answer when you need multi-step retry behavior. ## Configuration Steps - **Location:** Voice campaign (and dial profile, if your product separates policy by profile) — outbound / call context determination area. **Action:** Select one **policy type** (see table below). Save or publish per your change-management process. - **Location:** Failover configuration for the campaign (customer and agent call contexts, voice resources, priorities). **Action:** For **Failover** policy, assign **priority 1** to primary and **priority 2** (or higher) to secondary paths; verify mappings for each voice resource you use. - **Location:** Server preference store — scope as supported in your hierarchy (**system**, **contact center**, or **campaign**). **Action:** Set the `failoverNoAnswerTempDown` preference when you need to control whether **no-answer** adds contexts to the temporary unavailable list for **further steps on the same session** (see the note below the configuration table). - **Location:** Node flow designer (optional). **Action:** If you need **secondary after failure** inside one business process, add a second **Originate** or **Dial** after the failure transition and validate transitions (for example dial failed vs no answer) match your disposition design. ## Configuration parameters | Key / parameter | Description | How to configure | Constraints & options | Sample | | -------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | | `basic.single.call.context.type` | **Basic single** — exactly one configured call context; validates availability, limits, and optional voice resource match. | Voice campaign outbound call context policy: select **Basic single** (or equivalent label) and assign the single context. | One primary context; must remain within utilization and availability rules. | One customer call context tied to the campaign. | | `basic.multiple.call.context.type` | **Basic multiple** — round-robin over configured contexts; first that is available and under limits wins. | Policy: **Basic multiple**; list or assign the pool of contexts. | Order is round-robin across eligible contexts. | Three customer contexts in rotation. | | `multiple.try.round.robin.call.context.type` | **Multiple try round robin** — round-robin with **retry on early customer-leg failure** inside the same dial step when the product enables multiple-try for this policy only. | Policy: **Multiple try round robin**; configure the context pool. | **Only** this policy type gets **automatic in-step retry** on **initialized** (pre-ring) failure; selection remains round-robin, not strict priority. | Two contexts A/B; A fails pre-ring → automatic retry may attempt B. | | `phone.based.call.context.type` | **Phone-based** — maps destination numbers or patterns to call contexts and allowed voice resources. | Policy: **Phone-based**; maintain number or pattern to context mapping per product UI. | Depends on numbering plan and DID patterns. | Route `+1-800-…` to context “Tollfree-A”. | | `failover.call.context.type` | **Failover** — **priority-ordered** customer (and agent) contexts; respects temporary unavailable list and physical media ordering where applicable. Best for **primary → secondary** by priority. | Policy: **Failover**; set priority rows and failover campaign ↔ voice resource ↔ context mappings. | Does **not** auto-retry on pre-ring failure inside one step like multiple-try; use flow design for a second dial. | Priority 1 = primary CC; priority 2 = backup CC. | :::hint{type="info"} `failoverNoAnswerTempDown` — Server preference key: `failoverNoAnswerTempDown`. Configure in the **server preference store** at the hierarchy your deployment supports (**system**, **contact center**, or **campaign**), alongside other voice campaign parameters. When **true** (typical default), a **no-answer** outcome (rang, then disconnected) adds the relevant call context(s) to the **session** temporary-unavailable list so later determination on **that same flow instance** skips them—for example after a second **Originate** or **Dial** on a no-answer branch. When **false**, no-answer does **not** add to that list. **Applies to no-answer only**; it does **not** change pre-ring failure behavior and does **not** by itself trigger a retry. Sample: `true`. ::: :::hint{type="info"} If `failoverNoAnswerTempDown` is **true**, no-answer contributes to temporary unavailability for **any follow-up determination on the same node flow instance**—for example a second originate after no-answer. ::: :::hint{type="info"} `TEMP_UNAVAILABLE_CALL_CONTEXT_IDS_LIST` *(advanced)* — Session-scoped list of call context identifiers the engine should skip until the session ends or the list is cleared. It is usually maintained by the platform during dial outcomes; integrators or advanced node flows may read or pass it only where your product version documents it—not a typical administrator form field. Cleared for **new** calls or sessions; there is **no** time-based expiry in standard behavior—the scope is the **current** flow instance. Leave default unless you follow a certified integration pattern. ::: # Use Cases - **Stable single trunk or context** — Use **Basic single** when one outbound path is always correct. - **Load spread** — Use **Basic multiple** or **Multiple try round robin** when you want rotation across several eligible contexts. - **Disaster recovery / backup route** — Use **Failover** with explicit priorities; optionally add a **second dial step** in the flow after failure. - **Geographic or product-line routing by dialed number** — Use **Phone-based** when the destination number should decide the context. # Benefits - **Predictable priority** — Failover aligns with “try primary, then secondary” operations. - **Operational flexibility** — Policy choice is configuration- and flow-driven; no code deployment required for most scenarios. - **Clear knobs** — The `failoverNoAnswerTempDown` preference separates **no-answer** behavior from **pre-ring failure** behavior for the temporary unavailable list. # Limitations - **Failover** does **not** combine strict priority with **automatic in-step retry on pre-ring failure**; only **Multiple try round robin** does, and that policy uses **round-robin**, not strict primary-first ordering for every retry. - **Temporary unavailable** is **per session**, not a timed global ban; the next **new** call can select primary again. - **Chained dial steps** depend on correct **flow transitions** and on the temporary list **persisting** across the steps your design uses—validate end-to-end in your environment. - **Configuration alone** cannot enable “Failover + automatic in-step retry on pre-ring failure”; that combination requires the **Multiple try round robin** policy (with its selection semantics) or an explicit second dial in the flow. # Related Topics - **Call Routing** — Incoming routing policies and plans (related concepts: call context profiles, DID and source routing). - **Auto Dial** — Agent experience for outbound auto-dial and preview behaviors. - **Queue Management** — When outbound or blended behavior ties to queue and campaign setup.