Build and manage flows with Flow Designer

Publisher

Cisco Systems, Inc. (Webex Help Center)

URL

https://help.webex.com/en-us/article/nhovcy4/Build-and-manage-flows-with-Flow-Designer

Published

2026-09-03

Updated

unknown

Accessed

2026-09-05

HTTP status

200

License

Cisco proprietary documentation, all rights reserved; no-redistribution; short excerpts and locators only

Source notes citing this source

• No Cisco or Avaya source found in this research describes importing Avaya vectors or AACC Orchestration Designer applications into Flow Designer, so routing logic should be planned as a manual rebuild in Flow Designer. inferred in context
• The Flow Designer Blind Transfer activity transfers a call to an external dial number. in context
• Flow Designer has a GoTo activity that hands a contact from one flow to another and a Subflow activity that calls a reusable subflow from a main flow. in context
• Webex Contact Center flows can be exported and imported as JSON files. in context
• The Flow Designer Queue Contact activity places a contact in a Webex Contact Center queue, with skill-based routing and skill relaxation options. in context
• Webex Contact Center Flow Designer provides an activity named Business Hours, in the utilities group, which evaluates a business hours configuration during a flow. in context
• Flow Designer states that overrides and holidays each take precedence over working hours and does not state which takes precedence over the other when both apply on the same day. in context
• The activity takes the Default branch when none of the other branches evaluates. in context
• If any ordered list input on the activity is empty Flow Designer raises a validation error that must be resolved before the flow can be published. in context
• Flow Designer does not state which time zone the Business Hours activity evaluates in; the phrase does not occur anywhere in its Business Hours material. in context
• The Business Hours activity has 4 branches: Overrides, Holidays, Working Hours and Default. in context
• The Business Hours activity sets 4 output variables: WorkingHoursShift_name, Holidays_Name, Overrides_Name and Status, where Status records which branch was taken. in context
• If the current day is a holiday the activity takes the Holidays branch regardless of the shift timings in the chosen working hours. in context
• If the variable used for a dynamic binding does not contain a valid business hour identifier the flow moves to the error path. in context
• Neither Flow Designer nor the configuration article states what happens to a published flow when the business hours entity it is bound to is deleted. in context
• If the current time is defined as an override the activity takes the Overrides branch regardless of the shift timings in the chosen working hours. in context
• A flow binds a business hour either statically by choosing one from Control Hub or dynamically through a variable holding a business hour identifier. in context
• The article documents roughly 43 activities across the 4 groups. in context
• A flow variable marked agent editable lets the agent change its value during the interaction and the system passes the change back to the flow. in context
• A system variable for the entry point identifier is misspelled in the published variable list, so a flow copying it as printed resolves to nothing. in context
• A flow variable marked for external override can be changed from Control Hub by an administrator or a supervisor and the change applies immediately to calls already in progress. in context
• Only a small number of activities carry error branches beyond the generic undefined error node. in context
• Flow Designer organises its activities into 4 groups: contact handling, flow control, utilities and voice. in context
• Publishing an edited function updates every flow consuming that tagged version immediately. in context
• Flow Designer has one general error model: an activity's error path leads to the OnGlobalError event handler and the flow ends. in context
• Get Queue Info is the only contact handling activity with 3 named outcome branches: Success Insufficient Information Flow and Failure. in context
• The failure code table for the GoTo activity carries output variable names in its failure code column, so the article publishes no GoTo failure codes at all. in context
• The HTTP Request activity's output variables are named two incompatible ways in two sections of the same article. disputed in context
• JSON variables are capped at 16 KB, limited to 5 per flow, and cannot be passed through flow chaining. in context
• The activity set uses at least 5 different label conventions for the same idea of an outcome: Success and Failure on one activity onSuccess and onError on another Handled and Escalated and Error on a third Errored on its successor and True and False on the branching activities. field report in context
• Platform and release conditions are set per activity rather than by a general rule: some activities are limited to the Next Generation platform, one to Next Generation voice media, and one requires a local gateway alongside the real time media service. in context
• The Record activity's own documentation states that the recorded file is unencrypted and warns against recording anything sensitive. in context
• A recorded utterance can leave the platform through the HTTP Request activity, because the Record activity produces a file reference that a later activity can send outward. inferred in context
• A Recording Control activity uses a Boolean flow variable that overrides the recording policy set at tenant, queue and schedule level, in both directions. in context
• Only a small fraction of the article's 133 tables carry a caption element although its own numbering runs past table 30, so a caption search misses most of them. field report in context
• A flow may contain a maximum of 30 variables in total and that count includes global variables. in context
• A flow variable's type is fixed when it is created and cannot be changed afterwards. in context
• The Flow Designer article says nothing about transport security for any outbound call: encryption transport layer security in transit and at rest each occur 0 times. in context
• The word audit does not appear anywhere in the Flow Designer article, which describes no audit trail for any outbound call, for any change to an egress configuration, or for any use of the decrypt control. in context
• The BRE Request activity arrives with the caller's phone number already configured as a query parameter, so a flow author must actively delete it to stop it being sent. in context
• The BRE Request section names no authentication mechanism, no connector and no credential field, unlike the adjacent HTTP Request section which names Basic Auth and OAuth 2.0. in context
• The only per-interaction visibility into an outbound call is the Debug pane, which holds the most recent 100 interactions for the flow. in context
• Flow decryption applies only to calls initiated after the flow is published, so an investigator cannot enable it and then read what a flow sent before that point. in context
• Flow Designer carries at least 15 distinct activities or product features that can move data or media to a destination outside Webex Contact Center; the article never presents such a list itself. inferred in context
• The HTTP Request activity supports 7 HTTP methods, 4 of which write to the destination, and the article describes no mechanism for an administrator to restrict which methods a flow author may use. in context
• The raw session initiation protocol headers of an incoming call are stored in a flow variable in JSON form with up to 20 headers and 1000 bytes. in context
• No statement restricts the address an HTTP Request may target: allowlist firewall egress and residency each occur 0 times in the article. in context
• Cisco documents, from both ends, that a Record activity's captured caller audio can be uploaded to an external third-party server or API through the HTTP Request activity. in context
• A second file path for uploading a Record activity's captured caller audio to an external third-party server exists through the HTTP Request activity's Form Data content type, in addition to the File sub-option. in context
• Cisco states that audio recorded by the Record activity is in an unencrypted format and advises against recording sensitive information with it, and documents uploading that audio to a third-party server through the HTTP Request activity. in context
• Screen Pop sends flow variables to a free-text external URL by opening it in the agent's browser, with no connector, no credential and no domain restriction described. in context
• The article states that a secure variable prevents logging and storing of a value and never states whether a secure variable may be placed in an outbound payload. in context
• Cisco's most explicit outbound-data warning names 5 categories of information not to place in SIP headers, and it is scoped to the smallest payload the platform sends. in context
• Outgoing SIP headers in Webex Contact Center's Flow Designer are capped at 20 headers per INVITE. in context
• The Start Media Stream activity streams live caller and agent voice media out of the call, and the article states no destination, protocol, authentication, encryption or payload description for it. in context
• The Start Media Stream activity appears in Flow Designer's self-loop limit table with a limit of 20, so the platform documents the activity's existence even though the activity's own section omits its destination, protocol, authentication, encryption and payload details. in context
• The HTTP Request response timeout and retry count are each described as accepting any unlimited value. in context
• Turning off the Use Authenticated Endpoint toggle replaces the connector with a free-text Request URL typed into the flow, and the article names no allow-list, domain restriction or approval step for it. in context
• The Verify OTP activity carries an optional Notify URL that posts a status payload to any endpoint the flow author names, with no connector and no credential field. in context
• Crosswalk: Architect's Transfer to ACD action plays roughly the role of the Queue Contact activity in Webex Contact Center Flow Designer. Both put the contact in a queue and set its priority, but they state priority differently: Genesys treats one priority point as about one minute of wait time, while Webex says the highest-priority contact across all queues goes to the next available agent. inferred in context
• The Recording Control activity has no output variables of its own, so nothing the activity itself emits can be hooked to a record of the decision. in context
• The Recording Control activity's own documentation never uses the word override; it says priority is given to the user consent setting in the flow. field report in context
• Whether a recording consent decision is ever reportable is a flow-design choice: Cisco directs authors to use a global variable to generate a consent report and a local variable when they do not want to capture it. in context
• Setting the flow's consent configuration to No means the call is not recorded regardless of the configuration set at tenant, queue or recording schedule level. in context
• Setting the flow's consent configuration to Yes records the call regardless of the configuration set at tenant, queue or recording schedule level. in context
• The flow-level precedence covers only the decision whether to record; Continue On Transfer, Pause Resume Enabled and Pause Duration continue to follow the tenant, queue and recording schedule hierarchy. in context
• When consent is not configured in the flow, a Yes at any one of the tenant, queue or recording schedule levels records the call. in context
• Webex Contact Center Flow Designer exposes custom X-Headers from the incoming call through a 'Headers' output variable of the start activity (NewPhoneContact.Headers, now NewContact). in context
• Cisco tells Webex Contact Center flow developers not to put sensitive PII such as full names, Social Security numbers, addresses or financial data in custom SIP headers. in context
• Webex Contact Center Blind Transfer and Bridged Transfer activities have an Add Headers section that sends up to 20 custom key/value SIP headers in the outgoing INVITE. in context
• Webex Contact Center custom X-Headers are supported only for organisations using Webex Calling with a Local Gateway as the contact center telephony option. in context
• The Flow Designer Blind Transfer activity sends a call to an external or third-party dial number and is terminal, so the flow ends once the transfer executes. in context
• The Flow Designer Bridged Transfer activity temporarily sends a contact to an external destination such as an IVR while the flow keeps control, and the flow continues, for example to queue to an agent, when the external leg ends. in context
• Flow Designer voice and utility activities include Play Message, Menu, Collect Digits, Queue Contact, Virtual Agent V2, Callback, Business Hours, HTTP Request, Set Variable, Blind Transfer and Bridged Transfer. in context
• Flow Designer is the Webex Contact Center drag-and-drop tool for building the flows that route real-time calls and decide how agents are assigned. in context
• Flow Designer supports exporting and importing flows and offers prebuilt flow templates such as Simple inbound call to queue. in context
• Flow Designer versions carry Latest, Test or Live tags, and validation must be on with all errors resolved before a flow is published. in context
• CVP VXML applications cannot be imported into Flow Designer and must be rebuilt as flows, because the Flow Designer documentation describes no VXML, Call Studio or CVP import path. inferred in context
• Webex Contact Center Flow Designer exposes activity output variables and event output variables as predefined variables that a flow reads after an activity runs. in context
• Copy a flow is a documented Flow Designer operation, distinct from export and import. in context
• Export a flow and Import a flow are documented Flow Designer operations under Create and manage flows in the Webex Contact Center administrator documentation. in context
• The Webex Contact Center Flow Designer activity library is organised into four groups: Contact Handling, Flow Control, Utilities and Voice. in context
• Webex Contact Center Flow Designer treats functions as a first-class managed object, with documented procedures to create a function, manage functions and add a function to a main flow. in context
• Webex Contact Center Flow Designer provides an HTTP Request activity in the Utilities group for calling external systems from a flow. in context
• Webex Contact Center Flow Designer documents JSON variables as a distinct variable concept alongside custom flow variables, predefined variables and global variables. in context
• Webex Contact Center Flow Designer has no native database or SQL activity, so UCCX DB Read, DB Get, DB Write and DB Release logic has to be re-expressed as calls to an HTTP service. inferred in context
• Webex Contact Center Flow Designer has no version control feature; the flow version number counts the number of times the flow has been published. in context
• Webex Contact Center Flow Designer provides a Parse activity in the Utilities group for extracting values out of a structured response. in context
• Webex Contact Center flow expressions are written with Pebble template syntax, and Cisco documents a set of custom Pebble filters for use in flows. in context
• A Webex Contact Center flow must be validated and its errors fixed before it can be published, and the Publish button stays disabled until all errors are resolved. in context
• A Unified CCX application and the script it invokes correspond jointly to a single Webex Contact Center flow, and the rebuild is manual because no sheet or documented converter carries them. inferred in context
• A Webex Contact Center flow is a user-defined sequence of activities that executes in response to an event. in context
• The Queue Contact activity in Webex Contact Center Flow Designer is the mechanism that places a contact into a queue. in context
• Cisco's own worked example for Virtual Agent variable passing sends the caller's phone number, with key ANI and value NewContact.ANI. in context
• The JSON that reaches Google Dialogflow is parsed by a fulfilment application that Dialogflow reaches through a webhook configured in Dialogflow, which is a second hop outside Webex Contact Center. in context
• Webex Contact Center sends the Virtual Agent key-value parameters to Google Dialogflow as a JSON value in the request.query_param.payload object. in context
• The article announces that both virtual agent activities return a transcript URL and publishes no lifetime, authentication model or hosting location for it. in context
• Flow Designer ships 2 virtual agent activities, named Virtual Agent and Virtual Agent V2; the article names no third variant and no digital-channel equivalent. in context
• Cisco states that the Virtual Agent activity is powered by Google Dialogflow and that Dialogflow, not Webex Contact Center, matches the caller's speech to an intent. in context
• Virtual Agent V2 requires a Google CCAI connector and a CCAI configuration created in Control Hub, so the credential relationship with Google is held by the connector rather than by the flow. in context
• The Virtual Agent V2 procedure documents setting a custom input language by assigning a language code such as fr-CA to the Global_Language variable, and links to the supported voices and languages in Dialogflow ES. disputed in context
• The Virtual Agent V2 closing notes state that en-US is currently the only supported language. in context
• Three flow templates drive the Virtual Agent V2 activity against Webex AI Agent Studio agents rather than Google, so the same activity fronts two different AI backends with an identical field set. in context
• Virtual Agent V2 retries invalid or no-input errors an infinite number of times, as one of 5 settings that are fixed internally, do not appear in the interface and cannot be changed. in context
• The other 4 settings Virtual Agent V2 fixes internally are barge-in, the DTMF terminator, the DTMF no-input timeout and the DTMF inter-digit timeout. in context
• Only customers on the Next Generation platform can configure the Virtual Agent V2 activity. in context
• The sentence describing what Virtual Agent V2 sends outward names no vendor; it says the data goes to the integrated third-party AI platform. in context
• Cisco warns that the optional Variable Passing parameters on the Virtual Agent activity may contain personally identifiable information, and offers no masking, redaction or opt-out for that field. in context
• Flow Designer lists a Business Hours activity among its Utilities activities. in context
• Flow Designer's flow template list includes a Business hours usage template. in context
• Webex Contact Center Flow Designer documents Export a flow and Import a flow operations, which is the documented mechanism by which a flow built in one organisation can be carried into another. in context
• Flow Designer is reached in Control Hub under Services > Contact Center > Customer Experience > Flows. in context
• The Flow Designer guide says there is currently no version control feature, and that the flow version number counts how many times the flow has been published. in context
• The Webex Contact Center Flow Designer guide contains a top-level section 'Create and manage functions' with subsections Important considerations, Create a function, Manage functions, Add function to main flow, and FAQs. in context
• As of 24 September 2026, no source this run could read states the Functions execution contract: timeout, memory, package set, network egress rules, filesystem or database access. inferred in context
• In the Flow Designer guide, functions have their own section next to 'Create and manage subflows', and both sections have a step for adding the entity to a main flow. in context
• The Flow Designer help article lists flow templates including Hello World, Simple inbound call to queue, Menu auto attendant, Last agent routing and three AI Agent templates. in context
• The Flow Designer help article lists subflow templates for collecting callback information, error handling, HTTP data dip, queue treatment and scheduled callback. in context
• A new flow is started in Flow Designer from Manage Flows > Create Flows. in context
• Disconnect Contact is a terminating activity that disconnects an active call leg and may be used as many times as needed in a flow. in context
• Flow Designer has no version control feature; the flow version only counts how many times the flow has been published. in context
• Before using Flow Designer, entities such as entry points, queues and agents must be provisioned in Control Hub. in context
• The Queue Contact activity sends a contact to a queue chosen statically or from a variable, and supports skill requirements and an optional contact priority. in context
• A flow must be validated and its errors fixed before it can be published; the Publish button stays disabled until validation is on and all errors are resolved. in context
• The Webex Contact Center Flow Designer help article read in this run does not describe a dedicated CJDS activity, so using CJDS data for routing inside a Webex Contact Center flow probably means calling the Journey APIs from a generic HTTP request step. inferred in context
• Flow Designer is the Webex Contact Center tool for routing real-time calls. It is opened in Control Hub under Contact Center > Customer Experience > Flows. in context
• Flow Designer has no version control feature. The flow version number counts how many times the flow has been published, and version labels can be applied. in context
• Flow Designer has main flows, event flows (asynchronous flows triggered while the main flow runs) and reusable subflows. in context
• Flow Designer undo and redo covers the last 10 canvas actions. in context
• The Set Announcement activity in Flow Designer supports all 3 announcement types. in context
• One IVR flow can serve several languages: an audio prompt variable configured in Play Music, Play Message, Menu or Collect Digits selects the audio prompt dynamically for the language the customer chose. in context
• A prompt in an IVR activity can hold up to five audio prompts in total, counting audio files and audio prompt variables together. in context
• The Play Message activity cannot be interrupted by DTMF input, but when it sits after Queue Contact it is interrupted when an agent becomes available to take the call. in context
• If the Play Music duration is shorter than the audio file, the music plays for that duration; if it is longer than the file, the music loops and plays for five times the length of the file. in context
• The Play Music start offset moves the starting point inside the file: the documented example is a 60-second file with a 45-second offset and 30-second duration, which plays the last 15 seconds and then loops to play the first 15. in context
• The Play Music activity plays a .wav file while the customer waits in queue and is configured with an audio file, a music duration and a start offset. in context
• Flow Designer has a Preview prompt button that plays audio files and text-to-speech messages inside the designer, with a Play all option for both together, so prompts can be checked without publishing the flow or placing a PSTN call. in context
• A loop after Queue Contact must not contain only a Play Message activity; a loop that combines Play Music and Play Message is a valid call flow. in context
• In Flow Designer a Text-to-Speech toggle on the Menu, Play Message and Collect Digits activities turns on synthesized speech, after which the flow developer selects a TTS connector. in context
• A Queue To Agent activity can be chained with a Callback activity in both the Main flow and Event flows. in context
• The Callback activity is placed after a Queue Contact or Queue To Agent activity in the flow. in context
• A Queue To Agent activity can be chained with a Callback activity in both the Main flow and Event flows. in context
• If a flow never runs Queue Contact (or Queue To Agent), or takes that activity's error path, the contact is never placed in a queue. Agent availability, team mapping and skills then have no bearing on it, so a 'waiting with agents available' symptom should first be checked in the flow's execution path. inferred in context
• The Queue Contact activity's Check Agent Availability setting leaves teams with no available agents out of routing as the contact's time in queue progresses. It can be set to always check or be driven by a Boolean flow variable. in context
• The Queue Contact activity's error codes include INVALID_QUEUE (4), VTEAM_TRANSITION_LIMIT_REACHED (7, the contact hit the limit on being queued to multiple queues), OWNER_ASSIGNED_TO_INTERACTION (8) and INVALID_SKILL_NAME (9). in context
• If the Queue Contact activity is given an invalid skill value, all of that contact's skill requirements and relaxations are dropped. in context
• In the Queue Contact activity, skill relaxation lowers skill requirements after a wait-time threshold that defaults to 60 seconds. Enabling it copies the initial requirements as the starting point for the relaxation steps. in context
• Skill weights (1 to 1000) in the Queue Contact activity work only with Proficiency skills. Using them on another skill type gives error WEIGHT_NOT_SUPPORTED_FOR_SKILL_TYPE (13). in context
• The Queue To Agent activity's failure codes include AGENT_UNAVAILABLE (1), AGENT_NOT_FOUND (2), AGENT_NOT_LOGGED_IN (3) and VTEAM_TRANSITION_LIMIT_REACHED (7). An optional 'Park Contact if Agent is unavailable' setting holds the contact until that agent becomes available. in context
• Queue Contact and Queue To Agent take priorities P1 to P9, with P1 the highest. If a priority variable returns an invalid value, the priority defaults to 10. in context
• When an agent transfers a call to an entry point, the contact's priority changes to the priority assigned on the Queue Contact activity in the new flow. in context
• Flow Designer's voice activities include Collect Digits, Menu and Send Digits. in context
• In the Flow Designer Virtual Agent activity, Inter-digit Timeout defaults to 3 seconds and can be 0 to 30 seconds. in context
• In the Flow Designer Virtual Agent activity, Max No-Input Attempts defaults to 3 and can be 0 to 9. in context
• In the Flow Designer Virtual Agent activity's Advanced Settings, No-Input Timeout defaults to 5 seconds and can be 1 to 30 seconds; it applies to voice or DTMF input. in context
• In the Flow Designer Virtual Agent activity, the Terminator Symbol that ends caller input can be # or *. in context
• The Queue Contact activity outputs a QueueId variable on success and has a failure path with error codes such as INVALID_QUEUE. in context
• When the selected queue is skill-based, the Queue Contact activity lets the flow add one or more skill requirements to the contact. in context
• In the Queue Contact activity, Static Queue routes every contact to the single queue chosen in the Queue drop-down list. in context
• A flow must be validated and its errors fixed before it can be published. in context
• In the Queue Contact activity, Variable Queue selects the queue from a String flow variable, and a Fallback Queue receives the contact if the variable returns an invalid queue ID. in context
• A shared entry point serving several lines of business needs flow logic that sets a queue variable for Variable Queue selection, while one entry point per line of business can use a Static Queue. inferred in context
• The system prevents deleting an entry point or a flow that participates in flow chaining unless all chaining references are removed first; force-deleting skips validation silently with no UI error. in context
• Activity configuration can be copied and pasted across organisations and browsers. in context
• Flow Analytics does not support subflows internally; it tracks that a subflow was added to a main flow but excludes the subflow's own internal activity data. in context
• A flow can contain a maximum of 30 variables in total, and this count includes all global variables plus flow (custom) variables regardless of whether they are reportable or agent viewable. in context
• A Function activity's execution time is limited to 5 seconds. in context
• The Function activity supports 2 languages in its first phase: JavaScript (Node.js 22.x) and Python (3.13). in context
• An organization can have a maximum of 200 functions. in context
• A Function activity's code block is limited to a maximum of 5000 lines of code. in context
• The maximum memory allocated per function is 128 MB. in context
• Functions can use common native libraries but there is no support for custom modules inside the code block. in context
• Publishing a new version of a function immediately updates the behavior of all flows that consume the tagged version(s) of that function, including live production flows. in context
• The failure branch of the queue information activity is described as triggering when an interface fails or returns invalid values rather than in terms of the activity's own failure codes. in context
• Global variables cannot be marked as secure; only custom flow variables can be marked secure. in context
• Global variables are created by an administrator in the Provisioning module of Control Hub, and flow developers consume (add, edit default value of, or remove) them inside a flow rather than fully redefining them. in context
• Flow chaining lets 1 flow hand off to another flow or entry point using the GoTo terminating activity, and flow variables can be mapped across flows so data persists end-to-end. in context
• WarmTransfer's reading of the sources is that Flow Designer is a voice and IVR orchestration tool, and that digital-channel orchestration for chat, email, SMS and social runs on the separate Webex Connect product rather than on the activities Flow Designer publishes. inferred in context
• A JSON-type flow variable's value can be up to 16 KB in size. in context
• A flow can contain a maximum of 5 JSON-type variables. in context
• A JSON flow variable cannot be passed through flow chaining, so a value held in one does not reach the flow a GoTo hands off to. in context
• The queue information activities return minus one as an expected value rather than as an error when a figure does not apply. in context
• Flow Designer has no true version-control feature; the 'Flow version' number displayed is simply a count of how many times the flow has been published. in context
• If a flow developer does not configure an error handling path for an activity, execution falls back to the path defined in the OnGlobalError event handler. in context
• The activity set uses at least 5 label conventions for an outcome and one activity family names the same position Error on one activity and Errored on its successor. field report in context
• The position in queue value is set to the number of contacts already waiting plus one when the contact is not yet queued and the activity does not return empty after the contact leaves the queue. in context
• A flow cannot be published unless validation succeeds; the Publish flow button is disabled while the Validation toggle is off or any active errors exist. in context
• When publishing a flow, you can attach 1 or more version labels (such as Live, Test, or Dev); 'Latest' is applied by default and cannot be removed from the most recently published version. in context
• Accessing the Flow Designer application requires a Premium Agent License plus a user profile with rights to edit flows. in context
• Flow variables can be marked Secure, which prevents the system from logging or storing sensitive values and masks those values in the Flow Debugging pane. in context
• The system-enforced self-loop limit for the Advanced Queue Information activity is 1500 executions. in context
• The system-enforced self-loop limit for the Bridged Transfer activity is 75 executions. in context
• The Disconnect Contact activity has a self-loop limit of 0, meaning the system does not allow it to loop back into itself at all. in context
• The system-enforced self-loop limit for the Escalate Call Distribution Group activity is 750 executions. in context
• Flow-control activities (as opposed to call-handling activities) are not covered by the fixed per-activity self-loop table; instead they are subject to system-configured surge limits to prevent infinite looping. in context
• Collect Digits, Menu, Queue Contact, Queue to Agent, Set Caller ID and Set Contact Priority each carry a system-enforced self-loop limit of 100 executions. in context
• Self-loop limits exist to prevent activities from entering endless loops within a single interaction; exceeding the limit at runtime produces a warning that a loop was detected. in context
• Blind Transfer, Callback, Call Progress Analysis, Recording Control, Record, Schedule Callback, and FeedbackV2 each have a system-enforced self-loop limit of 10 executions. in context
• The system-enforced self-loop limit for both the Virtual Agent and Virtual Agent V2 activities is 50 executions each. in context
• The system extracts at most 20 headers from an incoming SIP INVITE message; if more than 20 are present, only the first 20 alphabetically sorted headers are extracted. in context
• Certain SIP header name patterns (e.g. X-Address, X-BNR-*, X-RTMS-*) are reserved for internal use; any custom header matching these patterns is dropped by default and never passed to Webex Contact Center. in context
• The Undefined Error node (used to route undefined system errors) is not present on 4 Flow Control activities: Start Flow, End Flow, HTTP Request, and Parse. in context
• The publish control is disabled while the validation toggle is off so a new flow cannot be published until the author turns validation on. in context
• Flow validation only checks for structural errors (required fields, valid structure); it cannot evaluate functions or confirm that variables resolve to expected values at runtime. in context
• A new flow is created in Control Hub under Contact Center > Customer Experience > Flows, then Manage Flows > Create Flows. in context
• The Disconnect Contact activity ends the call and is needed to disconnect a caller when no agent joins. in context
• The Flow Designer canvas has two tabs, Main Flow and Event Flows, that separate execution paths. in context
• For voice, the main flow starts from the NewPhoneContact start event. in context
• When the queue selected in Queue Contact uses skill-based routing, extra sections appear in the activity to configure skill requirements and skill relaxation. in context
• In the Queue Contact activity, Static Queue routes contacts to the single queue chosen in the Queue drop-down list. in context
• If the flow validation toggle is off the Publish button stays disabled, and after validation is enabled Publish stays disabled until all flow errors are resolved. in context
• The Queue Contact activity can instead use Variable Queue, which selects the queue dynamically from a queue variable. in context
• The Menu activity builds an IVR experience in a flow by playing a prompt that lets the caller enter a DTMF digit. in context
• The Menu activity's No-Input Timeout output is the error path taken after the entry timeout elapses, and the timeout duration is set in the activity's Advanced Settings. in context
• The Menu activity's Unmatched Entry output is the error path taken when the caller enters a DTMF digit that is not configured in Custom Menu Links. in context
• The Advanced Queue Information activity has its own failure-code table running from 1 (INVALID_REQUEST) to 48 (UNSUPPORTED_FLOW_ACTIVITY), including QUEUE_NOT_FOUND, FEATURE_NOT_ENABLED and DATABASE_OPERATION_FAILURE. in context
• Flow Designer event flows are optional and asynchronous to the main flow: they can fire at unpredictable points such as agent acceptance, and each event flow needs its own start and end with no activities shared with other flows. in context
• When diagnosing a queue failure you must read FailureCode against the table for the specific activity that set it, because Queue Contact and Advanced Queue Information use separate numbering. inferred in context
• FailureCode and FailureDescription output variables are documented on Advanced Queue Information, Escalate Call Distribution Group, Get Queue Info, Queue Contact, Set Contact Priority and Queue To Agent. in context
• The Flow Designer help article says there is currently no version control feature and that the flow version number just counts how many times the flow has been published. in context
• OnGlobalError is a Flow Designer event flow for global error handling; it runs when an activity has an error but its error path is not wired, so the flow falls through to the handler configured on the Event Flows tab. in context
• A Flow Designer flow cannot be published until validation is turned on and every validation error is resolved; the Publish button stays disabled otherwise. in context
• The published Queue Contact failure-code table appears to skip code 5 (it goes from 4 to 6), so a FailureCode of 5 cannot be interpreted from the current documentation. inferred in context
• Queue Contact failure code 4, INVALID_QUEUE, means the activity specified an invalid queue; code 2, INVALID_ROUTING_STRATEGY, means the chosen routing strategy is invalid. in context
• The Queue Contact activity exposes output variables QueueId (the queue the contact was placed in), FailureCode and FailureDescription (set when queuing fails). in context
• Queue Contact failure codes 9, 10 and 11 (INVALID_SKILL_NAME, INVALID_SKILL_CONDITION, INVALID_SKILL_VALUE) flag an invalid skill name, condition or value in a skills-based queuing request. in context
• Queue Contact failure code 12, INVALID_OPERATION_FOR_INTERACTION_STATE, means the contact is in a state that does not allow queuing, such as a terminated contact; code 8, OWNER_ASSIGNED_TO_INTERACTION, means the contact is already assigned to an agent. in context
• Queue Contact failure code 6, SYSTEM_ERROR, means the platform hit an internal error; code 1, INVALID_REQUEST, means the parameters in the activity are invalid; code 3, INVALID_WAIT_TIME, means the defined wait time is invalid. in context
• Queue Contact failure code 7, VTEAM_TRANSITION_LIMIT_REACHED, means the contact has hit the maximum number of times it can be queued to different queues. in context
• The Queue To Agent activity reports failure values including AGENT_UNAVAILABLE, AGENT_NOT_FOUND, AGENT_NOT_LOGGED_IN, AGENT_BUSY, FEATURE_NOT_ENABLED, INVALID_VTEAM_ERROR, VTEAM_TRANSITION_LIMIT_REACHED and INVALID_OPERATION_FOR_INTERACTION_STATE. in context
• In Queue Contact, a weight can only be set on a Proficiency-type skill requirement (otherwise failure code 13, WEIGHT_NOT_SUPPORTED_FOR_SKILL_TYPE), and weights must be integers from 1 to 1000 (otherwise code 14, INVALID_SKILL_WEIGHT). in context
• The Flow Designer article documents an Undefined Error path on at least these activities: Advanced Queue Information, Disconnect Contact, Escalate Call Distribution Group, Queue Contact, Screen Pop and Virtual Agent. in context
• Many Flow Designer activities offer an 'Undefined Error' output path that a flow developer can wire up to handle system errors during flow execution. in context
• In Webex Contact Center Flow Designer the flow validation toggle sits on the right of the footer pane and is off by default; turning it on starts backend validation and makes errors in the flow visible. in context
• Cisco sources describe flow versioning inconsistently: the help article says there is no version control feature, while a Cisco developer blog describes Flow Versioning with Dev, Test and Live labels, and the July 2026 release note says the Flow V2 APIs keep versioning. disputed in context
• Flow Designer automatically saves flows to avoid data loss, and autosave can be enabled or disabled. in context
• The Flow Designer properties pane shows flow history information, including the owner, the last edited date and the flow version number. in context
• The NewContact.FlowVersionLabel variable holds the version label of the flow version that is running, so flow logic can branch on labels such as Dev, Test, Live and Latest. in context
• The GoTo terminating activity chains flows by sending the contact to an entry point or to another flow. in context
• Cisco recommends version labels for taking a flow through development, test and live phases before deploying it to production. in context
• Version labels let different versions of the same flow be attached to different entry points or to a GoTo activity. in context
• While the Flow Designer validation toggle is off, the Publish button stays disabled. in context
• Reverting opens the selected earlier version in edit mode, where it can be changed and published again as a new version. in context
• A rollback by revert produces a new, higher version number that has to be published with Live again; version numbers never go backwards. inferred in context
• An administrator can save an unpublished flow draft and return to continue working on it later. in context
• A subflow can be published on its own, but its changes take effect only after the main flow that uses it is republished. in context
• A subflow can carry a version label such as Live, Dev or Test so the main flow can be tested end to end in each environment. in context
• The Flow Designer help article has separate procedures to copy, export, import and delete a flow and to apply version labels to a flow. in context
• A flow must be validated and its errors fixed before it can be published. in context
• Flow Designer has a View version history option that shows the version details of a flow. in context
• The Flow Designer HTTP Request activity fetches information from an external data source such as a CRM using standard HTTP protocols. in context
• When an HTTP Request activity is placed immediately after the Queue Contact activity, the HTTP Request may not retrieve the required data. in context
• The HTTP Request activity supports Basic Auth and OAuth 2.0 attributes for authenticated endpoints. in context
• Flow Designer functions let you write custom code inline in a code editor, in JavaScript or Python, and reuse it across flows. in context
• An organization supports at most 200 functions, and each function gets at most 128 MB of memory. in context
• Function code can be tested with sample values, showing outputs and errors, before the flow is published. in context
• Flow developers can create custom flow variables of type JSON and use them in the HTTP Request, Parse and Set Variable activities, including storing data extracted with a JSON path filter expression. in context
• Flow Designer has no version control feature; the flow version number counts how many times the flow has been published. in context
• The HTTP Request activity exposes an httpResponseBody output variable that returns the response body of the request. in context
• The HTTP Request activity exposes an httpStatusCode output variable that returns the HTTP status code of the request. in context
• Path Expression is required on each parsed variable row in Parse Settings; leaving it blank fails validation and the flow cannot be published. in context
• An error-handling path named Undefined Error can be configured to handle system errors. in context
• A flow must be validated and its errors fixed before it can be published; publishing stays disabled until errors are resolved. in context
• Flow Designer's Debug flows feature shows the call control path a production interaction took and can be filtered by interaction or session ID. in context
• In Flow Designer a flow must be validated and its errors fixed before it can be published. in context
• Flow developers can branch flow logic on the version label in execution using the NewContact.FlowVersionLabel variable. in context
• When a flow is published it can carry version labels such as Live, Test or Dev, and Latest is a default version label that cannot be removed from a flow version. in context
• When an activity has no error path configured the flow uses the default path defined in the OnGlobalError event handler on the Event Flows tab. in context
• Collect Digits accepts DTMF digits 0 through 9 and the letters A, B, C and D; the caller can enter # or * as a termination symbol, and the termination symbols cannot be used for any other purpose in the activity. in context
• The Collect Digits output variable CollectDigits.DigitsEntered stores the digits the caller entered in that activity instance. in context
• Collect Digits Inter-Digit Timeout is the longest the activity waits between digits, applies only after at least one digit is entered, and is skipped when the caller enters the terminator symbol. in context
• Collect Digits Maximum Digits is the most digits the caller can enter, with a default of 10. in context
• Collect Digits Minimum Digits defaults to 1, and input shorter than the minimum sends the flow down the Unmatched Entry path configured in Error Handling. in context
• In Collect Digits Advanced Settings, No-Input Timeout is the longest the activity waits for input before taking the Entry Timeout path; its default is 3 seconds. in context
• The Collect Digits activity prompts the caller for DTMF input such as an account number, and its prompt can use audio files, text-to-speech or both. in context
• Entry Timeout is the error output path a flow takes after the entry timeout elapses, so the caller does not sit idle too long; the duration is set in the activity's Advanced Settings. in context
• The Menu activity output variable Menu.OptionEntered stores the option the caller selected, a single digit from 0 to 9, and can be used in later activities to control the flow. disputed in context
• The Flow Designer Menu activity plays a prompt that lets the caller enter a DTMF digit, and the flow takes a different path depending on the digit entered. in context
• Unmatched Entry is the Menu activity's error output path taken when the caller enters a DTMF digit that is not configured in Custom Menu Links; Cisco advises that it play a message clarifying what is expected before looping back to the start of the activity. in context
• The name of the Menu activity's output variable changes with the activity label, so a Menu labelled differently exposes its option under that label rather than under 'Menu'. in context
• Because the Menu output holds a single digit while Collect Digits has minimum, maximum and terminator settings, Menu fits single-key choices and Collect Digits fits multi-digit strings such as account numbers or PINs. inferred in context
• A flow must be validated and its errors fixed before it is published; if the validation toggle is off the Publish button stays disabled. in context
• Flow Designer lets an activity's Undefined Error path be configured to handle system errors during flow execution, and an OnGlobalError event flow is available. in context
• In the Flow Designer Virtual Agent activity the DTMF terminator symbol, which the caller enters to end input, is # or * depending on configuration. in context
• The Virtual Agent activity output VVA.ErrorCode can hold no_error, max_no_input, term_char_without_input or system_error. in context
• In the Virtual Agent activity the Inter-digit Timeout defaults to 3 seconds and can range from 0 to 30 seconds. in context
• The Virtual Agent activity's Make Prompts Interruptible setting lets callers interrupt the virtual agent to make new requests or end the call. in context
• In the Virtual Agent activity the No-Input Timeout for voice or DTMF input defaults to 5 seconds and can range from 1 to 30 seconds. in context
• Flow Designer lists previewing an audio prompt within the flow as a capability. in context
• Flow Designer activities offer an Undefined Error error-handling path for system errors during flow execution. in context
• With the Flow Designer validation toggle enabled, the Publish button stays disabled until every error in the flow is resolved. in context
• In Play Message, TTS prompts can be given a language and voice, and a Make Prompts Interruptible option lets callers interrupt the prompt. in context
• The Set Caller ID activity can set the ANI based on the DNIS, the operation type or the participant type. in context
• A flow for an outdial entry point should not end with a Disconnect Contact activity, because it ends the flow and prompts wrap-up while the outdial call is still connected. in context
• Flows for outdial voice contacts support HTTP Request, Condition, Parse, Set Variable, Business Hours, End Flow, Screen Pop and the PreDial event, with event handlers such as PreDial and AgentOffered. in context
• Flows for outdial voice contacts do not support Queue Contact, Queue To Agent, Callback, Queue Lookup, Advanced Queue Information, Blind Transfer, Escalate Call Distribution Group, IVR Message, Menu or Survey. in context
• In an outdial flow the PreDial event is used to set the caller ID with the Set Caller ID activity, which must be used only in PreDial event flows as the terminal activity of that event flow. in context
• The Set Contact Priority activity is unsupported for outdial and campaign contacts. in context
• The AgentDisconnected event fires when the agent disconnects from a live call, including when the last agent disconnects and leaves the customer alone on the line. in context
• The PhoneContactEnded event fires when a live call disconnects and all participants are removed, and no IVR activity should be added after it because the flow will not work once the contact has ended. in context
• Event flows run asynchronously to the main flow, and the moment the system triggers an event flow cannot be predicted. in context
• The Flow Designer article names the event that precedes Feedback V2 'AgentDisconnected'. disputed in context
• The Feedback V2 activity is configured on the Event Flows canvas in Flow Designer after the AgentDisconnected event. in context
• Flow debugging in Flow Designer is a post-call process that shows the path a call took through the flow, which can be used to confirm whether the survey activities executed. in context
• A flow must be validated and its errors fixed before it can be published; with validation on, Publish stays disabled until all errors are resolved. in context
• A Disconnect Contact activity must follow the Feedback V2 activity to end the IVR call. in context
• Feedback V2 uses the Global_Language variable for the survey language unless the Override Language Settings toggle is enabled and a language is chosen in the activity; Global_Language defaults to en-US. in context
• Feedback V2 can optionally pass a customer ID, email and phone number and additional key-value variables with the survey response; a variable value may be a string, an integer or a double-curly-brace expression. in context
• The Queue To Agent activity triggers the AgentDisconnected event when the agent disconnects from a live call. in context
• Disconnect Contact is a terminating Flow Designer activity that disconnects an active leg of a call and has no output variables. in context
• Each event flow in the Event Flows canvas must have its own start and end and cannot share activities with another event flow. in context
• Flow Designer event flows run asynchronously to the main flow, and when the system will trigger an event flow cannot be predicted. in context
• The Feedback V2 Variable Passing section sends extra flow variables to Webex Experience Management as custom prefills, alongside the survey responses. in context
• The Feedback V2 Customer Information fields (Customer ID, Email and Phone Number) are optional. in context
• If the Feedback V2 Override Language Settings toggle is off, the Global_Language variable sets the survey language. in context
• If the caller hangs up before the agent, a Feedback V2 survey on the AgentDisconnected branch has no live caller to play to, so the caller never hears it. inferred in context
• Feedback V2 lives in the event flows of the same flow that queued the call, so a survey built in a flow the entry point does not run, or never published, will not play. inferred in context
• A Flow Designer flow must pass validation before it can be published; with the validation toggle off, the Publish button stays disabled. in context
• None of the sources read gives a maximum park time for Queue To Agent. Parking with no flow-side timer may leave a caller waiting as long as the preferred agent stays unavailable. inferred in context
• The Play Music activity has a Music Duration setting: the number of seconds the music plays in the queue. in context
• In the Queue To Agent activity, the Agent Variable setting is a flow variable, chosen from a drop-down, that holds the preferred agent's email address or ID. in context
• A flow can chain one Queue To Agent activity to another to try consecutive preferred agents. in context
• A flow can chain Queue To Agent to a Queue Contact activity so that the contact goes through a regular queue when none of the preferred agents is available. in context
• Queue To Agent triggers the AgentAccepted and AgentDisconnected events in the main flow's Event Flows tab. in context
• Queue To Agent defines eight failure codes: 1 AGENT_UNAVAILABLE, 2 AGENT_NOT_FOUND, 3 AGENT_NOT_LOGGED_IN, 4 FEATURE_NOT_ENABLED, 5 INVALID_VTEAM_ERROR (invalid reporting or recovery queue), 6 AGENT_BUSY, 7 VTEAM_TRANSITION_LIMIT_REACHED and 8 INVALID_OPERATION_FOR_INTERACTION_STATE. in context
• The Queue To Agent failure path is taken when the preferred agent is unavailable and parking is disabled, or when the variable lookup cannot find the preferred agent. in context
• Failure code 6, AGENT_BUSY, means the agent is available but already engaged in another call. in context
• Failure code 4, FEATURE_NOT_ENABLED, means the Agent-based Routing feature is not enabled. in context
• The Queue To Agent Agent Lookup Type setting is either Email or ID. in context
• If the preferred agent is unavailable and the park toggle is off, the contact fails to reach the agent. in context
• Queue To Agent writes the output variables QueueToAgent.AgentId, QueueToAgent.FailureDescription, QueueToAgent.FailureCode, QueueToAgent.AgentState and QueueToAgent.AgentIdleCode. in context
• Queue To Agent has a 'Park Contact if Agent is unavailable' toggle. Turning it on parks the contact against the preferred agent until that agent becomes available. in context
• Queue To Agent sends the contact to the recovery queue when it fails to deliver the contact to the preferred agent, when the agent does not answer, or when the agent rejects the contact. in context
• The Reporting Queue is chosen by queue ID from a drop-down, and Queue To Agent reports the contact's details against it. in context
• A static Queue To Agent contact priority runs from P1 to P9, where P1 is highest and P9 lowest. Priority ranks contacts queued to the same agent. in context
• Queue To Agent also has an Undefined Error path for system errors during flow execution. in context
• A variable Queue To Agent priority uses a flow variable that returns an integer from 1 to 9. in context
• In the recovery queue the contact goes to the longest available agent, and the recovery queue does not support skills-based routing. in context
• Flow Designer's templates include one called 'Last agent routing template'. in context
• A timed fallback can be built by parking the contact with Queue To Agent, playing music for a set Music Duration, and then running Queue Contact. Cisco documents the chaining and the duration setting but not how Queue Contact treats a contact that is still parked against an agent. inferred in context
• Advanced Queue Information outputs position in queue, logged-on and available agent counts for the current call distribution group and for all groups, and CurrentGroup and TotalGroups. in context
• The Escalate Call Distribution Group activity escalates a queued contact to its next or its last call distribution group. in context
• Escalate Call Distribution Group fails with CONTACT_NOT_QUEUED if the contact is not queued and FEATURE_NOT_ENABLED if the feature is not enabled in the tenant. in context
• Escalate Call Distribution Group outputs CurrentGroup (the group where the contact is parked) and TotalGroups (the number of groups in the queue). in context
• Get Queue Info returns position and estimated wait time in milliseconds, takes a lookback of 5 to 240 minutes, and takes an Insufficient Information branch when EWT is -1. in context
• Estimated wait time from Get Queue Info does not apply to team-assignment queues whose skills are assigned in the flow. in context
• Cisco recommends a short delay, such as a Play Message or Play Music activity, between Queue Contact and a following HTTP Request so the required data is available. in context
• Flow Designer documentation says the highest-priority contact across all queues, voice and digital, is assigned to the next available agent. in context
• In Queue Contact, the Check Agent Availability toggle excludes teams with no available agents from routing as time in the queue progresses. in context
• Queue Contact failure codes include INVALID_QUEUE, INVALID_SKILL_VALUE, VTEAM_TRANSITION_LIMIT_REACHED and INVALID_OPERATION_FOR_INTERACTION_STATE, exposed through FailureCode and FailureDescription. in context
• Queue Contact has a Set Contact Priority toggle; priority is a static level from P1 (highest) to P9 (lowest) or comes from a flow variable. in context
• Queue Contact routes to a single static queue or to a queue chosen by a Queue variable, with a Fallback Queue used if the variable returns an invalid queue ID. in context
• Queue Contact skill relaxation reduces or removes the contact's skill requirements once the contact has waited longer than the After waiting in the queue for value, in seconds. in context
• Queue Contact can add one or more skill requirements to the contact for the selected queue, each with skill, condition, value and, for proficiency skills, a weight from 1 to 1000. in context
• Flow validation detects structural errors, and the Publish button stays disabled until all validation errors are fixed. in context
• Flow Designer activities can have an Undefined Error path configured to handle system errors during flow execution. in context
• The AgentAccepted event is triggered by the Queue To Agent activity when an agent answers an inbound call. in context
• Flow developers choose which system, global and local variables appear on the voice call request popover and the Interaction Control pane, set their display order, and customise the label shown on the Agent Desktop. in context
• A Flow Designer flow must be validated and its errors fixed before it can be published. in context
• Flow Designer activity output variables are referenced with the activity label as prefix, in the form {{ActivityLabel.VariableName}}, so renaming an activity changes the name used downstream. inferred in context
• When a Screen Pop is shown Inside Desktop or in the existing tab, data an agent has entered in the pop for one call is lost if the agent accepts a new call; New browser tab avoids this. in context
• In Webex Contact Center a Screen Pop is a window or dialog box that appears in the agent's Desktop when the agent answers a customer call. in context
• The Screen Pop Desktop Label setting is a short custom display text that replaces the Screen Pop URL shown to the agent on the Desktop. in context
• The Screen Pop activity's Display Settings offer three options: New browser tab, Existing Screen Pop tab, and Inside Desktop. in context
• The Flow Designer Screen Pop activity is placed in Event Flows and typically uses the AgentAccepted event; it becomes relevant only after an agent is involved in the interaction. in context
• A Screen Pop configured as Inside Desktop is displayed as a tab in the Auxiliary Information pane of the Agent Desktop. in context
• The Screen Pop activity takes a Screen Pop URL and optional query parameters added as attribute-value pairs, and flow variables are inserted with {{variable}} syntax such as {{NewContact.ANI}}. in context
• Flow variables can be marked Secure, which prevents logging and storing of their values and masks them in the Flow Debugging pane, and secure variables can still be set Agent Viewable or Agent Editable. in context
• In Webex Contact Center Flow Designer, a Screen Pop is a window or dialog box that appears in the agent's Desktop when the agent answers a customer call. in context
• The Screen Pop activity becomes relevant only after an agent is involved in the interaction and typically uses the AgentAccepted and PhoneContactEnded events. in context
• The AgentAccepted event is triggered by the Queue To Agent activity when an agent answers an inbound call. in context
• Cisco instructs that the Screen Pop activity configuration is completed in the Event Flows tab of Flow Designer. in context
• The Screen Pop Desktop Label field sets short custom display text that replaces the Screen Pop URL on the Agent Desktop. in context
• Screen Pop for new digital channels must be configured in Connect Flow Builder, not with the Flow Designer Screen Pop activity. in context
• With the Existing Screen Pop tab display setting, the Screen Pop loads inside the existing browser tab and replaces the previous Screen Pop. in context
• With the Inside Desktop display setting, the Screen Pop appears as a tab in the Auxiliary Information pane of the Desktop. in context
• With the New browser tab display setting, the Screen Pop opens in a new browser tab every time without affecting the existing Screen Pop. in context
• A Screen Pop activity placed in the main flow before an agent is connected is unlikely to pop, because Cisco ties the activity to post-agent events such as AgentAccepted in the Event Flows tab. inferred in context
• The Screen Pop activity takes a Screen Pop URL naming the intended website, plus Query Parameters into which flow variables can be entered in the payload. in context
• Queue Contact skill requirement conditions depend on skill type: Boolean and Enum skills need no condition, and the available conditions are IS, IS NOT, >= and <=. in context
• Queue Contact sets QueueId when the contact is queued, and FailureCode and FailureDescription only when the activity fails. in context
• Queue Contact relaxation is configured by turning on Enable Skill Relaxation, which copies the initial requirements, and setting After waiting in the queue for in seconds before the relaxed requirements apply. in context
• Add Skill Relaxation Step adds further relaxation groups, and relaxation requirements can be added, edited or deleted. in context
• In the Queue Contact activity, selecting a queue that uses skill-based routing displays sections for skill requirements and skill relaxation, and if no skills are specified all available agents in the queue are eligible. in context
• A Queue Contact skill requirement value is either a Static Skill Value or a Variable Skill Value taken from a flow variable. in context
• A Queue Contact skill requirement weight must be an integer from 1 through 1000 and can be set only on a Proficiency-type skill. in context
• The Queue To Agent activity takes the preferred agent from a flow variable, looked up by the agent's Email or agent ID, and reports the contact against a chosen Reporting Queue. in context
• Queue To Agent can park the contact until the preferred agent is available, and moves it to the Recovery Queue if delivery to the preferred agent fails. in context
• Flow Designer custom flow variables can be of a Business Hours kind, intended to override business hours in an emergency shutdown. in context
• In the Flow Designer Case activity, if none of the cases are true the default case is taken. in context
• A Flow Designer Case activity accepts up to 20 case statements. in context
• The Flow Designer article does not state whether Case or Condition comparisons are case-sensitive, so a Status comparison's tolerance of casing differences is undocumented. inferred in context
• Flow Designer Condition activity expressions must be wrapped in double curly braces, and an expression without braces raises a Flow Error. in context
• The Business Hours activity takes the Default branch when none of the Overrides, Holidays or Working Hours nodes evaluates. in context
• Flow Designer's Default outcome and Webex Connect's no_match outcome cover the same situation (no working hours, holiday or override match) under different names. inferred in context
• Flow Designer raises a flow validation error if any of the Business Hours activity's ordered list inputs is empty. in context
• When the activity exits by the error path rather than one of its four nodes, the value left in Status is undocumented, so flows should not branch on Status after an error exit. inferred in context
• The Business Hours activity has four output nodes: Overrides, Holidays, Working Hours and Default. in context
• The Business Hours activity output variable Holidays_Name stores the name of the holiday when the current day is a holiday. in context
• The Business Hours activity takes the Holidays branch when the current day is a holiday in the Holidays list. in context
• Business Hours is documented under Activities in Utilities in the Flow Designer article, between BRE Request and Cryptographic Hash. in context
• If the Variable Business Hours ID is invalid, the flow moves to the error path. in context
• Flow Designer output variables of activities such as Collect Digits and Menu are referenced with the activity label as a prefix, for example {{CollectDigits.DigitsEntered}}, and the name follows the label. in context
• The name variables are documented only for the case where their node matches, so their content when another node is chosen (for example Holidays_Name on a Working Hours outcome) is undocumented. inferred in context
• The Flow Designer article does not state a data type for the Business Hours activity's Status output variable. in context
• The Flow Designer article does not publish the literal string values (exact spelling, casing or separators) that the Status variable holds at runtime. in context
• The article names the node Overrides but the Override branch and the Status prose use the singular override, so the documentation itself is inconsistent about the spelling a Status comparison should use. inferred in context
• The Business Hours activity takes the Override branch when the current time is defined as an override in the Overrides list. in context
• Override flow settings let administrators and supervisors change flow parameters such as business hours without opening the flow. in context
• The Business Hours activity output variable Overrides_Name stores the name of the override that matches the current time. in context
• Because the article only states that holidays and overrides each beat working hours, which Status value results when an override and a holiday both match the same moment is not determinable from the documentation. inferred in context
• Holiday lists and overrides take precedence over working hours when their timing coincides with the current shift timing. in context
• The Business Hours activity output variable WorkingHoursShift_name stores the name of the shift defined in the working hours. in context
• In Schedule Details the Business Hours activity offers Static Business Hours (pick a Control Hub business hour) and Variable Business Hours (a variable holding a Business Hour ID). in context
• The Flow Designer article describes the Status values in prose as working hours, holidays, override, or default. in context
• By analogy with other activities, Status is probably referenced as {{<Business Hours activity label>.Status}}, but the Business Hours section does not show this syntax. inferred in context
• The Status output variable stores which of the activity's output nodes was chosen during flow execution. in context
• The Webex Contact Center Flow Designer Business Hours activity exposes an output variable named Status. in context
• The Business Hours activity supports an Undefined Error path for system errors during flow execution. in context
• The Business Hours activity uses working hours, holidays and overrides defined in Control Hub to decide which branch the flow takes. in context
• For Variable Business Hours the variable must contain the correct Business Hour ID obtained from Control Hub. in context
• Working Hours is the primary node of the Business Hours activity and evaluates the shift timing of the selected business hour. in context
• The Flow Designer help article includes a section titled Debug flows. in context
• A subflow used by any published main flow cannot be deleted, whether or not that main flow is live or attached to an entry point; it must first be removed from the main flow or the main flow deleted. in context
• Because a subflow cannot call another subflow, logic shared by two subflows has to be duplicated in each or moved up into the main flow. inferred in context
• Because subflow changes reach a main flow only when it is republished and subflows carry their own labels, a safe promotion publishes and labels the subflow first, then republishes and relabels each consuming main flow. inferred in context
• A subflow is invoked from within a flow to run logic without linking to an entry point and without leaving the main flow. in context
• Version labels let different versions of the same flow be attached to different entry points or to a GoTo activity. in context
• A version label such as Live, Dev or Test can be attached to a subflow so the main flow can be tested end to end in the matching environment. in context
• Latest is the default version label; it cannot be removed from a flow version during publishing, and other labels are applied alongside it. in context
• Publishing a draft associates the Latest label with the new version, and only one version holds the Latest label at a time. in context
• Local variables can be passed to other flows through the GoTo activity or the Subflow activity. in context
• An organization can create at most 200 subflows. in context
• A subflow cannot be linked directly from an entry point or from a queue routing strategy. in context
• Subflows must be invoked from main flows; a subflow cannot invoke another subflow. in context
• Subflows are created at the organization level, and a flow developer can view and invoke subflows that exist in the same organization. in context
• A subflow can be published independently, but changes made in the subflow take effect only after the main flow is republished. in context
• Flow Designer lets developers break large flows into smaller subflows that can be reused across multiple flows to handle specific tasks, reducing the complexity of building large flows. in context
• A subflow can be reused multiple times within one main flow and across main flows in the organization. in context
• The Flow Designer article documents subflow templates for collecting callback information, error handling, HTTP data dip, queue treatment and scheduled callback. in context
• If a subflow plays text-to-speech, the audio plays in English by default unless the subflow defines a variable named like Global_VoiceName or a subflow variable is mapped with the value from the main flow. in context
• Flow Designer activities offer an error-handling path called Undefined Error for system errors that occur during flow execution. in context
• If an agent transfers a call to an entry point, the contact priority changes to the priority assigned by the Queue Contact activity in the new flow. in context
• Flow variables marked agent viewable are displayed on Agent Desktop during the interaction. in context
• Flow Designer's Case activity branches on one variable against multiple values, and the Condition activity branches true or false on an expression. in context
• Flow Designer has a debug capability that traces flow executions and shows activity outputs and variable values. in context
• Because the channel runs the flow version carrying the selected label, moving that label back to the previous version or pointing the channel at another label should withdraw a newly published AI agent flow. inferred in context
• A validated flow is published with publish notes and version labels Latest, Dev, Test or Live, and the channel's routing flow setting chooses which labelled version runs. in context
• Flow Designer's Parse activity takes an input variable, a content type such as JSON, and JSONPath expressions that map values into flow variables. in context
• The Queue Contact activity places a contact in a queue chosen either statically or from a flow variable that yields a valid queue ID. in context
• VirtualAgentV2.ErrorCode reports values including no_error, max_no_input and system_error. in context
• With the Inside Desktop or existing-tab display option, data an agent is entering in the screen pop is lost if the agent accepts a new call. in context
• Screen Pop display options are New browser tab, Existing Screen Pop tab (replaces the previous pop) and Inside Desktop (a tab in the Auxiliary Information pane). in context
• The Flow Designer Screen Pop activity applies only once an agent is involved and is typically placed in the AgentAccepted and PhoneContactEnded event flows. in context
• The Screen Pop activity takes a Screen Pop URL, Query Parameters built from flow variables in {{variable}} syntax such as {{NewContact.ANI}}, and a Screen Pop Desktop Label shown as the hyperlink text. in context
• A connector governs credentials rather than destinations: the Flow Designer article describes a connector as a common location to store credentials, and the same activity lets a flow author turn off the authenticated-endpoint toggle and type a destination URL directly. inferred in context
• Flow Designer states that only active connectors appear in the connector drop-down of the text-to-speech activities. in context
• Cisco describes the Salesforce connector as essentially creating the domain section of the URL for an HTTP Request. in context
• The call progress analysis activity may appear in an event flow only on the callback failure handler. in context
• The callback failure handler sanctions the callback, queue to agent and queue contact activities inside an event flow and can route a contact to a different destination. in context
• No source states whether 2 event flows can run at once, whether one can run while the main flow is mid-activity, or what happens when an event fires while its own handler is still running. in context
• The outbound campaign call result event flow is restricted to the play music and play message activities, and a virtual agent may not be used in it directly. in context
• The phone contact ended event is described as available with selected call handling activities and, 2 sentences later, as exposed only by the queue contact activity. disputed in context
• The corpus holds one placement rule that produces no runtime warning when broken, and the article states no general rule about when event flow placement is validated. inferred in context
• The set caller identity activity may be used only in an event flow, and is the terminal activity of the pre-dial event flow. in context
• An event flow shares custom flow variables and event output variables with the main flow, and both canvases contribute to the flow's average duration and average activities per contact. in context
• Neither the blind transfer nor the bridged transfer activity may be placed in an event flow. in context
• Cisco states that a tenant may not see the undefined error node at all and must contact support to have the feature enabled. in context
• The HTTP Request activity publishes no failure code variable no failure branch and no undefined error node and a flow can only test the returned status code by hand. in context
• No sentence in the article relates the generic undefined error node to a failure code variable: the phrase error branch occurs 0 times and failure branch once without defining what the branch carries. in context
• The HTTP Request retry setting applies when the status code is in the 500 range so a rate-limit response or a connection timeout is not retried. in context
• A Flow Designer failure code integer means different things in different activities: code 3 is feature not enabled insufficient data invalid wait time agent not logged in no answer and invalid queue depending on which activity set it. in context
• Four failure names carry different code numbers in different activities: invalid queue is 5 4 4 3 and 3 across 5 activities system error is 1 in one activity and 6 in 5 others feature not enabled is 3 3 4 and 5 and invalid operation for interaction state is 12 and 8. in context
• The article publishes 10 runtime failure code tables holding 57 codes in total: 6 for advanced queue information 3 for escalate call distribution group 4 for get queue info 13 for queue contact 8 for queue to agent 2 for set contact priority 5 for bridged transfer 6 for callback 7 for record and 3 for schedule callback. in context
• Two of the 7 record activity error codes are published with an empty description column so a flow comparing the error code against a name has nothing to compare for them. field report in context
• Restrictions are stated for some activities and not others: blind transfer is terminal and unsupported for consults, bridged transfer is unsupported in outbound and event flows and for a contact already assigned to an agent, and most activities state none. field report in context
• Error handling runs 3 tiers deep: an activity's own error path, then a global error event flow, then the flow ends. in context
• An event flow is an asynchronous extension of the same flow on its own canvas, with a unique start and end and no activities shared with the main flow. in context
• Flow Designer documents 43 activities in 4 groups: 11 contact handling, 7 flow control, 8 utilities and 17 voice. in context
• One of the four activities Cisco lists as having no undefined error path documents such a path in its own section, so the catalogue and the activity's own page disagree. disputed in context
• Flow Designer names 9 event handlers on the Event flows tab: OnGlobalError AgentAccepted PhoneContactEnded AgentOffered AgentDisconnected CallbackFailed PreDial ContactAniUpdated and OutboundCampaignCallResult. in context
• The utilities list misspells the cryptographic hash activity where its own section heading spells it correctly. field report in context
• Error path coverage follows the activity class rather than the activity: the flow control class holds 3 of the 4 activities with no error node and the contact handling class holds every activity with a named outcome branch. inferred in context
• A tenant without the error handling feature enabled sees no undefined error node on any activity, so an automated coverage check over its flows reports every activity as uncovered, and nothing in the flow distinguishes that from a tenant that has the feature and has connected no error paths. inferred in context
• Four activities have no undefined error node at all: Start Flow End Flow HTTP Request and Parse. in context
• Cisco instructs a reader who cannot see the undefined error node in any activity to contact support to have the feature enabled. in context
• Twenty activities document the undefined error node and 19 of them carry the same boilerplate sentence describing it. in context
• An activity with no error path connected falls through to the global error handler on the event flow canvas and a flow with neither ends when an error occurs. in context
• Cisco warns that the End Flow activity should not be used in an interactive voice response flow, because doing so may result in dead air and the call may not disconnect. in context
• Most activities that describe failure carry the detail in a failure code and a failure description variable rather than in a branch. in context
• A table headed as GoTo activity error codes contains output variable descriptions rather than failure codes. field report in context
• The named branches on the menu and collect digits activities are a no-input timeout and an unmatched entry. in context
• The Parse activity's own section describes an undefined error path and the error handling section lists Parse among 4 activities that lack one. disputed in context
• The article gives 2 incompatible statements about whether a flow missing an error path can be published. disputed in context
• Only 6 Flow Designer activities carry error branches beyond the generic undefined error node: menu, collect digits, virtual agent, virtual agent version 2, queue to agent and cryptographic hash. in context
• The virtual agent error code variable takes 4 values: no error, maximum no input, termination character without input, and system error. in context
• Neither the Flow Designer article's self-loop table nor the system limits article's copy lists Function among the throttled activities, so no published ceiling caps how many times a function can be re-entered in one interaction. in context
• Console logs are not exposed in the function test runner; a function can surface debug information only by setting and reading a custom output string array. in context
• The only sentence characterising the function execution environment names a packaging and invocation model rather than a network policy. in context
• The complete published statement on what code inside a function may use is that common native libraries are available and custom modules are not supported; the native libraries are never enumerated. in context
• No sentence in the functions documentation or its frequently asked questions uses the words network, internet, outbound, egress, sandbox, isolation, firewall, allow-list or proxy. in context
• One frequently asked question states that a function sets 1 JSON output variable and another states that multiple variables can be set from the code block. disputed in context
• Publishing a function after editing its source code or settings updates the change immediately in every flow consuming those tagged versions, and the only stated safeguard is an instruction to be mindful. in context
• Functions carry 6 published limits: 200 functions per organisation, 128 MB of memory per function, 5000 lines of code, 5 seconds of execution, 10 input variables and 1 JSON output variable. in context
• Flow Designer functions run author-written JavaScript on Node.js 22.x and Python 3.13, described as available in the first phase. in context
• Function code is written with language-specific static analysis and the article never states what that analysis checks for. in context
• Supervisors as well as administrators can manage functions, gated by a Function setting in the user profile that can be set to Edit, View or None. in context
• The article names 10 operator symbols 2 filters and 1 function of the expression language and delegates the rest to an external wiki. in context
• Cisco advises against complex expressions when configuring multiple variables in one Set Variable activity and defines neither complex nor the consequence. field report in context
• An invalid expression surfaces either as design-time error code FC1009 or as a system error during execution of the Set Variable activity and the article never relates the two. in context
• Flow Designer input fields use the open-source Pebble Templates expression syntax and the article names no version of it. in context
• An expression written without its double curly braces throws a flow error and the article states this for the Condition activity only. in context
• A text-to-speech message of more than one line requires a Pebble escape filter for the system to play it. in context
• Cisco instructs that the now function not be used to obtain the current time in milliseconds because it uses a simple date format and directs the author to the epoch filter instead. in context
• Cisco instructs that single quotes be used instead of double quotes inside an expression and gives no reason. in context
• Two unrelated expression syntaxes are used in the same activity configuration: the Pebble double brace form for flow variables and a JSON path form for parsing a response body. in context
• Flow validation checks expressions for structural errors only and cannot evaluate a function or check that a variable resolves to the expected value. in context
• The strongest candidate for the setting that governs recording through a blind transfer is Continue On Transfer, named in Flow Designer at tenant, queue or recording schedule level. inferred in context
• The Recording Control activity carries no stated placement restriction, where the blind transfer and bridged transfer activities in the same catalogue state theirs. in context
• The Recording Control activity takes a single boolean flow variable and no output variable, and is configured through one setting that enables or disables recording for the call. in context
• The 3 actors that can affect a recording have different abilities: a flow can force it on or off, an agent can pause and resume but not during a consult, and a supervisor can do neither. inferred in context
• The blind transfer activity is terminal and the flow ends once the transfer executes, so nothing of the transferring flow runs after it. in context
• The bridged transfer activity is the one case where Cisco says the call flow continues, and the destination it names is a third-party interactive voice response or automatic call distribution system rather than an entry point. in context
• Going to another flow allows variables to be mapped by hand, where going to an entry point carries global variables only when name and data type both match. in context
• The GoTo activity's entry point option tells the reader to choose it if the flow logic should change based on the active routing strategy at the time of transfer. in context
• On a blind transfer to an entry point or dial number, the target is presented to the receiving entry point flow as a dialled number identification service value, available in a flow variable the receiving flow can evaluate. in context
• Cisco states that when a contact arrives at an entry point the routing engine checks which entry point routing strategy is active at the given time and follows that configuration. in context
• The Start Flow activity is the only documented way into a flow, and no activity enters another flow part way through. in context
• A transfer to an entry point runs that entry point's routing strategy afresh rather than continuing the transferring flow. inferred in context
• Start Media Stream carries a system-enforced self-loop limit of 20 per interaction, and the system limits article publishes the same value. in context
• A whisper announcement applies to incoming calls and to a blind transfer to an entry point. in context
• While a whisper announcement plays, the agent cannot put the call on hold, transfer it, conference it, or request supervisor assistance, and those become available again when the announcement completes. in context
• A whisper announcement is not included in the call recording. in context
• A whisper announcement can be combined with a compliance message and an agent greeting, and the whisper plays first. in context
• Flow Designer documents a Set Whisper Announcement activity that plays a brief prerecorded message to an agent just before the agent connects with a caller, where the caller hears ringing. in context
• The word whisper names 2 different Webex Contact Center capabilities: a flow activity that plays a recorded message to an agent before connection, and a supervisor action the Analyzer schema counts as whisper coaching. field report in context
• The Blind Transfer activity cannot carry flow variables to the destination, because the destination flow is not executed. in context
• A call transferred to an Entry Point Directory Number stays part of the existing interaction, and reporting and call records continue to use the same interaction ID. in context

Cite this source record

APA

WarmTransfer. (2026, September 3). Build and manage flows with Flow Designer. WarmTransfer. https://warmtransfer.net/knowledge/sources/cisco-help-nhovcy4-wxcc-flow-designer

BibTeX

@misc{warmtransfer-cisco-help-nhovcy4-wxcc-flow-designer,
  title  = {Build and manage flows with Flow Designer},
  author = {{WarmTransfer}},
  year   = {2026},
  url    = {https://warmtransfer.net/knowledge/sources/cisco-help-nhovcy4-wxcc-flow-designer},
  note   = {Cisco Systems, Inc. (Webex Help Center), accessed 2026-09-05}
}