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

Claims citing this source

• Webex Contact Center Flow Designer provides an activity named Business Hours, in the utilities group, which evaluates a business hours configuration during a flow. fact 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. fact in context
• The activity takes the Default branch when none of the other branches evaluates. fact 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. fact 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. fact in context
• The Business Hours activity has 4 branches: Overrides, Holidays, Working Hours and Default. fact 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. fact 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. fact 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. fact 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. fact 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. fact 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. fact in context
• The article documents roughly 43 activities across the 4 groups. fact 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. fact 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. fact 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. fact in context
• Only a small number of activities carry error branches beyond the generic undefined error node. fact in context
• Flow Designer organises its activities into 4 groups: contact handling, flow control, utilities and voice. fact in context
• Publishing an edited function updates every flow consuming that tagged version immediately. fact in context
• Flow Designer has one general error model: an activity's error path leads to the OnGlobalError event handler and the flow ends. fact in context
• Get Queue Info is the only contact handling activity with 3 named outcome branches: Success Insufficient Information Flow and Failure. fact 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. fact 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. fact 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-pattern 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. fact in context
• The Record activity's own documentation states that the recorded file is unencrypted and warns against recording anything sensitive. fact 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. inference 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. fact 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-pattern in context
• A flow may contain a maximum of 30 variables in total and that count includes global variables. fact in context
• A flow variable's type is fixed when it is created and cannot be changed afterwards. fact 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. fact 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. fact 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. fact 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. fact 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. fact 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. fact 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. inference 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. fact 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. fact in context
• No statement restricts the address an HTTP Request may target: allowlist firewall egress and residency each occur 0 times in the article. fact 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. fact 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. fact 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. fact 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. fact 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. fact 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. fact in context
• Outgoing SIP headers in Webex Contact Center's Flow Designer are capped at 20 headers per INVITE. fact 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. fact 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. fact in context
• The HTTP Request response timeout and retry count are each described as accepting any unlimited value. fact 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. fact 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. fact 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. fact 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-pattern 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. fact 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. fact 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. fact 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. fact 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. fact 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. fact 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. fact 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. fact 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. fact 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. fact 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. fact 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. fact in context
• Only customers on the Next Generation platform can configure the Virtual Agent V2 activity. fact 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. fact in context
• The Set Announcement activity in Flow Designer supports all 3 announcement types. fact 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. fact in context
• Activity configuration can be copied and pasted across organisations and browsers. fact 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. fact 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. fact in context
• A Function activity's execution time is limited to 5 seconds. fact in context
• The Function activity supports 2 languages in its first phase: JavaScript (Node.js 22.x) and Python (3.13). fact in context
• An organization can have a maximum of 200 functions. fact in context
• A Function activity's code block is limited to a maximum of 5000 lines of code. fact in context
• The maximum memory allocated per function is 128 MB. fact in context
• Functions can use common native libraries but there is no support for custom modules inside the code block. fact 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. fact 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. fact in context
• Global variables cannot be marked as secure; only custom flow variables can be marked secure. fact 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. fact 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. fact 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. inference in context
• A JSON-type flow variable's value can be up to 16 KB in size. fact in context
• A flow can contain a maximum of 5 JSON-type variables. fact 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. fact in context
• The queue information activities return minus one as an expected value rather than as an error when a figure does not apply. fact 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. fact 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. fact 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-pattern 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. fact 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. fact 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. fact in context
• Accessing the Flow Designer application requires a Premium Agent License plus a user profile with rights to edit flows. fact 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. fact in context
• The system-enforced self-loop limit for the Advanced Queue Information activity is 1500 executions. fact in context
• The system-enforced self-loop limit for the Bridged Transfer activity is 75 executions. fact 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. fact in context
• The system-enforced self-loop limit for the Escalate Call Distribution Group activity is 750 executions. fact 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. fact 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. fact 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. fact 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. fact in context
• The system-enforced self-loop limit for both the Virtual Agent and Virtual Agent V2 activities is 50 executions each. fact 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. fact 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. fact 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. fact 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. fact 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. fact 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. inference in context
• Flow Designer states that only active connectors appear in the connector drop-down of the text-to-speech activities. fact in context
• Cisco describes the Salesforce connector as essentially creating the domain section of the URL for an HTTP Request. fact in context
• The call progress analysis activity may appear in an event flow only on the callback failure handler. fact 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. fact 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. fact 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. fact 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. inference 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. fact 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. fact in context
• Neither the blind transfer nor the bridged transfer activity may be placed in an event flow. fact 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. fact 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. fact 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. fact 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. fact 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. fact 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. fact 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. fact 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-pattern 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-pattern in context
• Error handling runs 3 tiers deep: an activity's own error path, then a global error event flow, then the flow ends. fact 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. fact in context
• Flow Designer documents 43 activities in 4 groups: 11 contact handling, 7 flow control, 8 utilities and 17 voice. fact 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. fact in context
• The utilities list misspells the cryptographic hash activity where its own section heading spells it correctly. field-pattern 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. inference in context
• Four activities have no undefined error node at all: Start Flow End Flow HTTP Request and Parse. fact in context
• Cisco instructs a reader who cannot see the undefined error node in any activity to contact support to have the feature enabled. fact 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. fact 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. fact in context
• Most activities that describe failure carry the detail in a failure code and a failure description variable rather than in a branch. fact in context
• A table headed as GoTo activity error codes contains output variable descriptions rather than failure codes. field-pattern in context
• The named branches on the menu and collect digits activities are a no-input timeout and an unmatched entry. fact 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. fact in context
• The virtual agent error code variable takes 4 values: no error, maximum no input, termination character without input, and system error. fact 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. fact 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. fact in context
• The only sentence characterising the function execution environment names a packaging and invocation model rather than a network policy. fact 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. fact 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. fact 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. fact 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. fact 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. fact in context
• Function code is written with language-specific static analysis and the article never states what that analysis checks for. fact 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. fact 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. fact in context
• Cisco advises against complex expressions when configuring multiple variables in one Set Variable activity and defines neither complex nor the consequence. field-pattern 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. fact in context
• Flow Designer input fields use the open-source Pebble Templates expression syntax and the article names no version of it. fact in context
• An expression written without its double curly braces throws a flow error and the article states this for the Condition activity only. fact in context
• A text-to-speech message of more than one line requires a Pebble escape filter for the system to play it. fact 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. fact in context
• Cisco instructs that single quotes be used instead of double quotes inside an expression and gives no reason. fact 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. fact 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. fact 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. inference 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. fact 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. fact 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. inference 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. fact 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. fact 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. fact 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. fact 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. fact 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. fact in context
• The Start Flow activity is the only documented way into a flow, and no activity enters another flow part way through. fact in context
• A transfer to an entry point runs that entry point's routing strategy afresh rather than continuing the transferring flow. inference 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. fact in context
• A whisper announcement applies to incoming calls and to a blind transfer to an entry point. fact 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. fact in context
• A whisper announcement is not included in the call recording. fact in context
• A whisper announcement can be combined with a compliance message and an agent greeting, and the whisper plays first. fact 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. fact 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-pattern in context
• The Blind Transfer activity cannot carry flow variables to the destination, because the destination flow is not executed. fact 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. fact 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}
}