What Settings Containers do and when you need one

A reusable blob of settings

A Settings Container is a named place to store a large block of configuration that the codebase's PHP and Perl scripts can read by ID. Rather than scatter dozens of related options across screens, you write them once into a container and point a script at it. Several built-in scripts already do this, including the one that sends dispositioned email and a back-end settings script that pulls container values at runtime.

If you have never touched one, that is fine: most teams run for a long time before they need a container. You reach for one when a feature explicitly asks for a container ID, not as a routine config step.

The fields on a container

• Container ID: 2 to 40 characters, no spaces or special characters. This is how scripts find it.
• Container Notes: a descriptive name so you remember what it is for.
• Container Type: mostly categorization, controlling where the container shows up. A special READ_ONLY type is maintained by external processes and cannot be edited in the admin screens. Default is OTHER.
• Admin User Group: restricts who can view the record, defaulting to --ALL--.
• Container Entry: the actual contents, written as key-value lines that the consuming script knows how to parse.

flowchart LR
  A["Admin writes Container Entry"] --> B["Saved under Container ID"]
  B --> C{"Container type"}
  C -->|OTHER| D["Editable in admin"]
  C -->|READ ONLY| E["Maintained by external process"]
  D --> F["Script reads container by ID"]
  E --> F
  F --> G["Feature uses the settings"]

When you actually need one

The container entry is just structured text, and the format depends entirely on what reads it. A few real uses make the idea concrete:

• An email template for the disposition email script, with the subject, body, and merge fields like first name and phone number filled in at send time.
• A timezone list for scheduled callbacks, so a Scheduled callback respects each customer's local rules.
• Per-lead dial timeouts keyed off a field, or a list of which AMD outcomes count as a machine.
• Filtering rules for which leads or which Pause code entries get hidden, and two-factor authentication settings like code length and expiry.

Because the same mechanism backs a Disposition email and a security setting, a container is best thought of as plumbing: it holds whatever a specific feature needs and nothing more. Warning: the exact key names and format are dictated by the script that consumes the container, so copy a known-good example for the feature you are enabling rather than inventing keys.

Containers are an advanced corner of the admin, and like most of it they respect user-group scoping. The VICIdial users and groups multi-team guide explains how that scoping carries across the system.

Several container uses revolve around extra fields on a record. If you are adding your own data points, how custom user fields work is the place to start.

Want a managed VICIdial box where the advanced bits are documented and ready? Try VICIfast and your dialer is online in under 40 seconds.