Transfer

Overview

The Service Transfer Component is an action node focused on queue management and routing contacts for human interaction. Its main function is to transfer the customer or support ticket from automated self-service to the waiting queue of a department or to the inbox of a specific agent.

Synchronous Execution Behavior: When the flow reaches this component, automated support enters a hold. If there are nodes connected to its output, the flow will remain blocked at this step and any subsequent block will only be executed when the human operator formally closes/ends the support request.

Configuration Parameters

The component configuration determines the exact destination where the interaction history and contact will be sent. It is made up of two essential criteria:

• _Department ( Required Field):* Defines the general destination queue or department (e.g.: _Technical Support, Finance, Sales). When an option is selected, the ticket enters the distribution logic configured for that queue (such as rotating queues or round-robin).

• User (Optional): Allows the support request to be directed directly and by name to a specific operator in the system. If filled in, the system ignores the department's general queue and delivers the ticket directly to the selected agent's inbox.

Visual Builder

The builder has a clean interface focused on a fast experience to avoid bottlenecks in automation:

• Dynamic Drop-Down Menus: The selectors for Department and User perform real-time searches in the platform's database, showing only options that are active and available at the time of configuration.

• Field Validation: The visual asterisk indicator (*) next to the field Department signals to the flow administrator that the component cannot be saved or executed without a macro destination queue being defined.

Special Operators

In ticket routing and transfer systems, the "special operators" control contingency behavior and data transition rules:

• Post-Service Trigger (Closure Callback): The output of this component acts as a system event listener. It intercepts the human agent's closing action and uses this trigger to unblock the flow, allowing the automatic sending of scheduled message blocks for after-sales or support.

• Metadata Injection: When the transfer is made, the component automatically attaches the entire log and the variables collected in the previous nodes of the flow (such as the captured name or the reported issue) and delivers them to the human agent's panel.

• Overflow Logic (Native Fallback): If the User explicitly selected is offline or logged out of the system, the component triggers internal contingency rules, sending the ticket back to the general queue of the Department set to avoid leaving the customer without a response.

Practical Examples

The table below shows classic use cases for this component in distributing support requests:

Selected Department	Selected User	Next Node Connected to the Output	Practical Use Case
Finance	None (General Queue)	WhatsApp Question Component with CSAT survey	The customer is assisted by Finance. As soon as the agent finishes the ticket, the flow unblocks and sends the satisfaction survey automatically.
Advanced Support	Agent João	None (End of flow)	Directed routing to João. The flow ends permanently upon transfer, leaving the cycle open only on the agent's screen.
Sales	None (General Queue)	Hablla Component (Update Person to "Customer")	The lead is transferred to the sales reps. After the sales rep successfully finishes the support interaction, the system updates the contact status in the database.