The beginner VICIdial admin pathway: from first login to first report

Start here

Follow this order: secure the first Admin login; understand user versus phone; create the campaign rules; load a synthetic list; prepare one agent; then validate reports. A real carrier and a real call are later, separately authorized steps — not a prerequisite to learning the Admin menu. This lesson names the order; the terminology lesson right before it named the vocabulary each step depends on.

This lesson is a decision framework, not a set of screen-by-screen instructions — those already exist in the dedicated lessons this one points to. What belongs here instead is the ordering logic itself: which decision has to come before which, and why skipping ahead produces a screen that looks broken when it is actually just incomplete.

Treat this as the map you keep open in a second tab while working through the dedicated lessons, rather than a lesson you read once and set aside. Each of the other lessons in this stage assumes you already know where its step sits in this larger order.

Six steps is deliberately few. VICIdial's Admin menu exposes far more than six screens, but almost everything else you will eventually configure is a variation on, or an addition to, one of these six foundational objects. Learning this order first makes every later, more specialized lesson in this curriculum easier to place.

The idea in plain language

VICIdial's objects link together. A campaign that draws queued leads needs an active list with eligible leads. An agent needs a working station to join the calling session. A report with no activity may show no rows or zero totals. Building in this order gives each screen a clear purpose before you touch the next one.

A beginner who jumps straight to campaign setup before creating a user and station will find controls that reference objects that do not exist yet, and will likely conclude something is wrong with the software rather than with the order of operations. The six-step sequence below exists specifically to prevent that misdiagnosis.

The same logic explains why a real carrier and a real call sit outside this six-step sequence entirely rather than as a seventh step. Every one of the six steps here can be completed and verified with entirely synthetic data and no outside connection; a carrier introduces cost, compliance obligations, and a live external dependency that belong to a separately authorized decision, not a default next click.

Notice also that 'report' is the last step, not the first thing you check. A beginner who opens a reporting screen before any of the first five steps exist will see an empty result and may reasonably wonder whether reporting itself is broken; it is not, there is simply nothing yet for it to summarize.

This ordering also mirrors how an experienced administrator actually debugs a stalled campaign months later: check the account and login first, then the user-and-station pairing, then the campaign's own rules, then whether the list actually has eligible leads, then agent readiness, and only then look at what the reports show. The six-step build order and the troubleshooting order are the same order, read in the same direction.

Keeping the build order and the troubleshooting order identical is not a coincidence this lesson is pointing out for its own sake — it is why the order is worth learning properly the first time, rather than as a checklist to forget once your first campaign is running. You will use this same order again, in reverse thought but the same direction of investigation, the first time something in a real campaign stops working.

See the campaign schema take shape

Now that you have a read-only database account from the previous stage, you can confirm the campaign-related tables exist before you ever open the Admin screen that manages them. `SHOW TABLES LIKE` matches table names against a pattern, the same way a filename wildcard matches files — the percent sign stands in for any sequence of characters.

For this admin exercise, confirm the database identity before inspecting the prepared synthetic campaign. If the linked option file is root-owned mode 600, an authorized administrator can start the client with sudo mysql --defaults-file=/etc/vicidial-readonly.cnf, then run SELECT CURRENT_USER(), DATABASE(); and confirm the intended read-only account and schema before these queries. Do not expose or copy its credentials.

SHOW TABLES LIKE 'vicidial_campaign%';

• How many tables the pattern matches on your build
• Whether the table names match what the previous lessons already told you to expect

Follow the six-step order

Use this as a checklist while you work through the existing lessons this pathway points to; it changes nothing on the server by itself. Each numbered line corresponds to one or more dedicated lessons elsewhere in this curriculum — this worksheet is the map between them, not a replacement for any of them.

1. Secure the first Admin login2. Create one user and one phone/station3. Build the campaign rules4. Load one synthetic list5. Get one agent ready6. Read the first report

Ready for the next lesson

Continue to the existing first-login tour next, then its campaign, lead-loading, first-agent-call and pacing lessons in that order — a real carrier is a separate, optional stage after this one. The first-agent-call lesson uses an internal test destination rather than a real phone number, so you can complete it without a carrier at all.