Fix: "ingroup is not valid" when transferring to a closer queue

You send a call to a closer queue and the transfer bounces back with ingroup is not valid. The customer is still on your line and nothing moved. This error comes from the transfer-conference logic checking the in-group you handed it and deciding it is not a single active queue it can route to. The fix is almost always about the exact value you passed.

When an in-group is required

Routing a call to another VICIdial agent, the LOCAL_CLOSER path, requires an Ingroup value, and so do consultative transfers. The value must be one single active in-group, not a list and not a blank. There is a reserved option, DEFAULTINGROUP, that resolves to the default in-group for the in-group or campaign the call originated from, which is handy when you do not want to hard-code a queue name. If the value you pass does not match a real, active queue, you get ingroup is not valid.

Cause, check, fix

flowchart TD
  A[ingroup is not valid] --> B{Did you pass an ingroup at all}
  B -->|No| C[Add ingroup_choices for LOCAL_CLOSER]
  B -->|Yes| D{Is it a single active in-group}
  D -->|No| E[Remove list or fix typo]
  D -->|Yes| F{Does the closer campaign allow it}
  F -->|No| G[Add the in-group to allowed inbound groups]
  F -->|Yes| H[Try DEFAULTINGROUP reserved value]
  H --> I[Re-run the transfer]

First, make sure you actually passed an in-group. A LOCAL_CLOSER transfer with no in-group value will fail this check, and so will a consultative transfer that leaves the field blank. Second, confirm you passed exactly one active in-group, spelled correctly and case-correct. A trailing space, a comma-separated list, or a queue that has been turned off all read as invalid, because the function expects a single live queue and nothing else. Third, check that the in-group is live and that the receiving Closer campaign is set to accept it as an allowed inbound group, otherwise the queue exists but the closer cannot pull from it. When the transfer is rejected the agent stays connected to the customer and lands back on the same screen, so nothing is lost, but the handoff simply did not happen and the agent has to try again.

If you want the transfer to follow whatever the originating campaign considers its default, swap your literal queue name for DEFAULTINGROUP. That removes a whole class of typos and keeps the transfer working even if you rename queues later. The same validation applies to remote-agent call control, so the lesson carries over: one active in-group, exactly named.

Avoiding it in the agent screen

Most agents never type a queue name; they pick from a dropdown of allowed transfer groups, which keeps a clean handoff one click away from the Disposition step. Keeping that list tight and accurate is the real prevention. If a queue shows in the list but still throws this error, it usually means the queue was deactivated after the list was built, or the Closer campaign was never set to take it. Sync those two and the dropdown stops lying to your agents. For the broader handoff context, see the transfers and closers guide, and for the mechanics of routing to a queue see how to transfer a call to an in-group.

If wiring up closer queues and keeping them in sync is more work than it should be, a managed dialer keeps the in-group and campaign settings aligned for you. See our pricing for details.