Outbound Call Context Policies
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
- 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).
- 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.
- 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.
- 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
- 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.
- 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. |
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.
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.
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.