How to turn on email in System Settings before agents can use it

Before any agent can answer an inbound email, VICIdial needs to know email is allowed on the system at all. That permission lives in one global toggle, and until you set it, every email group and email account you build sits idle. It is the first switch to flip, and it is easy to forget because the rest of the setup happens on the Inbound and Admin tabs, far away from where this lives.

The one setting to change

In Admin, open System Settings. Find the field called Allow Emails and change it to 1. That is the master switch. With it set to 0, the email features stay hidden and nothing you configure downstream will run. With it set to 1, VICIdial starts treating email as a real channel that an Agent can be staffed on alongside calls.

Think of it the way you think about the difference between a dialer that is allowed to make outbound calls and one that is not. The setting does not create anything by itself. It just removes the lock so the parts you build next actually do something.

What this switch does not do

Turning on Allow Emails is necessary, but on its own it is not enough to make email work end to end. Two server-side pieces still have to be in place, and they live outside the web admin where this setting sits:

• An "E" keepalive added to one, and only one, of your servers, so the system actually services email.
• The inbound email parser scheduled to run every minute on that same single server, so new messages get pulled in and turned into work for agents.

There is also a short list of Perl modules the server needs before the parser will run. None of that is something you do in System Settings, but it is worth knowing the switch is step one of several, not the whole job. If you are running a single managed box this is handled for you; on a self-built cluster it is a server task.

Where this fits in the setup order

Doing things in the right order saves a lot of confusion. Flip the global switch first, then grant the right user permission to configure accounts, then build the email group and the email account, then attach the group to a Campaign so people can staff it.

flowchart TD
  A["System Settings"] --> B{"Allow Emails"}
  B -->|set to 0| C["Email features hidden"]
  B -->|set to 1| D["Email channel enabled"]
  D --> E["Add E keepalive on one server"]
  D --> F["Schedule inbound email parser"]
  E --> G["Build email group and account"]
  F --> G
  G --> H["Assign group to a campaign"]

Because Allow Emails is global, you only ever do this once per installation. After that, the rest of the work is about routing: which email group an incoming message lands in, which agents are eligible, and how each Lead gets pulled onto a screen and worked. When the agent finishes a message they apply a Disposition just like they would after a call, and they become available again.

Once Allow Emails is on, the next move is to grant the configuring user access to Email Accounts. That step is covered in letting a user configure Email Accounts. For the full walk-through of how email groups, accounts, and routing fit together, start with the inbound email and chat guide. If you would rather skip the server-side wiring entirely and have the parser and keepalive set up for you, our pricing page lays out the managed plans.