When to use DEFAULTINGROUP in an in-group transfer

When you use ra_call_control with stage=INGROUPTRANSFER, the ingroup_choices parameter normally takes the name of a specific Ingroup. But there is one reserved value: DEFAULTINGROUP. Passing DEFAULTINGROUP tells VICIdial to send the call back to whichever Campaign or in-group originally routed the call to the Remote agent, without your app needing to know or store that name.

What DEFAULTINGROUP actually does

VICIdial tracks the origin of every call sent to a remote agent. When the call arrived, it came from a specific in-group or campaign. DEFAULTINGROUP tells VICIdial to look up that origin and route the call back there. The caller re-enters the queue they came from, and the next available agent in that in-group picks up. Your app does not need to pass the in-group name because VICIdial already has the origin stored against the call ID.

This is useful in environments where calls can arrive from multiple in-groups depending on what a caller selected in an IVR, which DID (direct inward dialing) they called, or what time of day it is. Rather than building logic in your app to figure out which in-group to name, you pass DEFAULTINGROUP and let VICIdial handle the lookup itself.

DEFAULTINGROUP vs a named in-group

A named in-group in ingroup_choices sends the call to a specific destination regardless of where it originated. Use a named in-group when you always want to route to a particular team — for example, always sending escalations to an ESCALATIONS in-group regardless of which campaign generated the lead. Use DEFAULTINGROUP when the right destination is the origin queue itself, which is a common pattern when a remote agent decides they cannot handle a call and wants to return it to the pool. This Cold transfer back to origin avoids hardcoding an in-group name that might change, be renamed, or not apply to every call the agent receives.

Decision flowchart

flowchart TD
  A["Need to INGROUPTRANSFER?"] --> B{"Do you know the target in-group?"}
  B -->|Yes| C{"Is it always the same in-group?"}
  C -->|Yes| D["Use named in-group in ingroup_choices"]
  C -->|No| E{"Does target vary by call origin?"}
  E -->|Yes| F["Use DEFAULTINGROUP"]
  E -->|No| G["Add routing logic to your app first"]
  B -->|No| H["Use DEFAULTINGROUP"]
  F --> I["Call returns to originating queue"]
  D --> J["Call enters the named in-group"]

An example request

A real request using DEFAULTINGROUP looks like this: http://server/agc/api.php?source=test&user=6666&pass=1234&agent_user=1028&function=ra_call_control&stage=INGROUPTRANSFER&ingroup_choices=DEFAULTINGROUP&value=Y0316001655000402028. The only difference from a named in-group request is the word DEFAULTINGROUP in the ingroup_choices field. The response follows the same SUCCESS: ra_call_control transferred format, showing the agent user, call ID, and the actual name of the in-group the call was routed to, so you can log where it ended up.

When DEFAULTINGROUP will not work as expected

DEFAULTINGROUP depends on VICIdial having a stored origin for the call. If a call arrives at the remote agent through an unusual path that does not record an originating in-group or campaign, DEFAULTINGROUP may route incorrectly or return an error. In those cases, name the in-group explicitly. If the call origin varies but you do know it at runtime — for example, your CRM tracks which Campaign the call came from — you can pass the name directly and avoid any ambiguity. Always check the success response body to see which in-group was actually used, and add logging to your integration so unexpected routing is visible early.

For the full setup of in-group transfers, see how to transfer a remote-agent call into an in-group. How remote agents receive calls in the first place is explained in the remote agents guide. If you want to test ra_call_control on a real system without building a server, our managed VICIdial plans get you a running dialer in under 40 seconds.