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