# Global Configurations

Global Configurations administration tasks.

# Media Files

Maintain global media files available beyond a single tenant.

Use **Admin > Media Files** to manage media files.

This page is a starting point for administrators: review existing records, add only the objects needed by the deployment, and keep names consistent across tenants, routing, and provisioning.

## Typical Workflow

1. Open the menu entry and confirm whether the record already exists.
2. Create or edit the record with a descriptive name and only the required options first.
3. Save the record and reopen it to verify the stored values.
4. Check dependent objects before deleting anything that may be used by routing, billing, provisioning, or reporting.

## Documentation Example

For documentation and testing, use names prefixed with **Docs Demo**. Existing PBX nodes should be reused as examples; do not create additional nodes unless the deployment actually requires them.

# Custom Destinations

Maintain global custom destinations shared with tenants.

Use **Admin > Custom Destinations** to manage custom destinations.

This page is a starting point for administrators: review existing records, add only the objects needed by the deployment, and keep names consistent across tenants, routing, and provisioning.

## Typical Workflow

1. Open the menu entry and confirm whether the record already exists.
2. Create or edit the record with a descriptive name and only the required options first.
3. Save the record and reopen it to verify the stored values.
4. Check dependent objects before deleting anything that may be used by routing, billing, provisioning, or reporting.

## Documentation Example

For documentation and testing, use names prefixed with **Docs Demo**. Existing PBX nodes should be reused as examples; do not create additional nodes unless the deployment actually requires them.

# Feature Codes

Maintain global feature codes.

Use **Admin > Feature Codes** to manage feature codes.

This page is a starting point for administrators: review existing records, add only the objects needed by the deployment, and keep names consistent across tenants, routing, and provisioning.

## Typical Workflow

1. Open the menu entry and confirm whether the record already exists.
2. Create or edit the record with a descriptive name and only the required options first.
3. Save the record and reopen it to verify the stored values.
4. Check dependent objects before deleting anything that may be used by routing, billing, provisioning, or reporting.

## Documentation Example

For documentation and testing, use names prefixed with **Docs Demo**. Existing PBX nodes should be reused as examples; do not create additional nodes unless the deployment actually requires them.

# Email Templates

Maintain shared email templates.

Use **Admin > Email Templates** to manage email templates.

This page is a starting point for administrators: review existing records, add only the objects needed by the deployment, and keep names consistent across tenants, routing, and provisioning. The source form exposes these main blocks or fields: Email.

## Typical Workflow

1. Open the menu entry and confirm whether the record already exists.
2. Create or edit the record with a descriptive name and only the required options first.
3. Save the record and reopen it to verify the stored values.
4. Check dependent objects before deleting anything that may be used by routing, billing, provisioning, or reporting.

## Documentation Example

For documentation and testing, use names prefixed with **Docs Demo**. Existing PBX nodes should be reused as examples; do not create additional nodes unless the deployment actually requires them.

## Main Fields

<table id="bkmrk-field-or-blockpurpos"><thead><tr><th>Field or block</th><th>Purpose</th></tr></thead><tbody><tr><td>Email</td><td>Review this value in relation to the object being configured and the tenant or system scope where it is used.</td></tr></tbody></table>

# Email Template Profiles

Group email templates into profiles.

Use **Admin &gt; Email Template Profiles** to manage email template profiles.

This page is a starting point for administrators: review existing records, add only the objects needed by the deployment, and keep names consistent across tenants, routing, and provisioning.

## Typical Workflow

1. Open the menu entry and confirm whether the record already exists.
2. Create or edit the record with a descriptive name and only the required options first.
3. Save the record and reopen it to verify the stored values.
4. Check dependent objects before deleting anything that may be used by routing, billing, provisioning, or reporting.

## Documentation Example

For documentation and testing, use names prefixed with **Docs Demo**. Existing PBX nodes should be reused as examples; do not create additional nodes unless the deployment actually requires them.

# Do Not and Only Allow Call Lists

Maintain global call allow or block lists.

Use **Admin &gt; Do Not and Only Allow Call Lists** to manage do not and only allow call lists.

This page is a starting point for administrators: review existing records, add only the objects needed by the deployment, and keep names consistent across tenants, routing, and provisioning. The source form exposes these main blocks or fields: Find a number.

## Typical Workflow

1. Open the menu entry and confirm whether the record already exists.
2. Create or edit the record with a descriptive name and only the required options first.
3. Save the record and reopen it to verify the stored values.
4. Check dependent objects before deleting anything that may be used by routing, billing, provisioning, or reporting.

## Documentation Example

For documentation and testing, use names prefixed with **Docs Demo**. Existing PBX nodes should be reused as examples; do not create additional nodes unless the deployment actually requires them.

## Main Fields

<table id="bkmrk-field-or-blockpurpos"><thead><tr><th>Field or block</th><th>Purpose</th></tr></thead><tbody><tr><td>Find a number</td><td>Review this value in relation to the object being configured and the tenant or system scope where it is used.</td></tr></tbody></table>

# Music on Hold

Maintain global music-on-hold definitions.

Use **Admin &gt; Music on Hold** to manage music on hold.

This page is a starting point for administrators: review existing records, add only the objects needed by the deployment, and keep names consistent across tenants, routing, and provisioning.

## Typical Workflow

1. Open the menu entry and confirm whether the record already exists.
2. Create or edit the record with a descriptive name and only the required options first.
3. Save the record and reopen it to verify the stored values.
4. Check dependent objects before deleting anything that may be used by routing, billing, provisioning, or reporting.

## Documentation Example

For documentation and testing, use names prefixed with **Docs Demo**. Existing PBX nodes should be reused as examples; do not create additional nodes unless the deployment actually requires them.

# Conditions

Maintain global conditions that tenants can reference.

Use **Admin &gt; Conditions** to manage conditions.

This page is a starting point for administrators: review existing records, add only the objects needed by the deployment, and keep names consistent across tenants, routing, and provisioning.

## Typical Workflow

1. Open the menu entry and confirm whether the record already exists.
2. Create or edit the record with a descriptive name and only the required options first.
3. Save the record and reopen it to verify the stored values.
4. Check dependent objects before deleting anything that may be used by routing, billing, provisioning, or reporting.

## Documentation Example

For documentation and testing, use names prefixed with **Docs Demo**. Existing PBX nodes should be reused as examples; do not create additional nodes unless the deployment actually requires them.

# Short Numbers

Maintain global short-number mappings.

Use **Admin &gt; Short Numbers** to manage short numbers.

This page is a starting point for administrators: review existing records, add only the objects needed by the deployment, and keep names consistent across tenants, routing, and provisioning.

## Typical Workflow

1. Open the menu entry and confirm whether the record already exists.
2. Create or edit the record with a descriptive name and only the required options first.
3. Save the record and reopen it to verify the stored values.
4. Check dependent objects before deleting anything that may be used by routing, billing, provisioning, or reporting.

## Documentation Example

For documentation and testing, use names prefixed with **Docs Demo**. Existing PBX nodes should be reused as examples; do not create additional nodes unless the deployment actually requires them.

# Conduits

Maintain global conduits for integrations and data exchange.

Use **Admin &gt; Conduits** to manage conduits.

This page is a starting point for administrators: review existing records, add only the objects needed by the deployment, and keep names consistent across tenants, routing, and provisioning.

## Typical Workflow

1. Open the menu entry and confirm whether the record already exists.
2. Create or edit the record with a descriptive name and only the required options first.
3. Save the record and reopen it to verify the stored values.
4. Check dependent objects before deleting anything that may be used by routing, billing, provisioning, or reporting.

## Documentation Example

For documentation and testing, use names prefixed with **Docs Demo**. Existing PBX nodes should be reused as examples; do not create additional nodes unless the deployment actually requires them.

# Reserved Numbers

Reserve numbers that tenants should not use.

Use **Admin &gt; Reserved Numbers** to manage reserved numbers.

This page is a starting point for administrators: review existing records, add only the objects needed by the deployment, and keep names consistent across tenants, routing, and provisioning.

## Typical Workflow

1. Open the menu entry and confirm whether the record already exists.
2. Create or edit the record with a descriptive name and only the required options first.
3. Save the record and reopen it to verify the stored values.
4. Check dependent objects before deleting anything that may be used by routing, billing, provisioning, or reporting.

## Documentation Example

For documentation and testing, use names prefixed with **Docs Demo**. Existing PBX nodes should be reused as examples; do not create additional nodes unless the deployment actually requires them.

# Caller ID Blacklist

Maintain global caller ID blacklist entries.

Use **Admin &gt; Caller ID Blacklist** to manage caller id blacklist.

This page is a starting point for administrators: review existing records, add only the objects needed by the deployment, and keep names consistent across tenants, routing, and provisioning.

## Typical Workflow

1. Open the menu entry and confirm whether the record already exists.
2. Create or edit the record with a descriptive name and only the required options first.
3. Save the record and reopen it to verify the stored values.
4. Check dependent objects before deleting anything that may be used by routing, billing, provisioning, or reporting.

## Documentation Example

For documentation and testing, use names prefixed with **Docs Demo**. Existing PBX nodes should be reused as examples; do not create additional nodes unless the deployment actually requires them.

# AGI Scripts

Maintain global AGI script definitions.

Use **Admin &gt; AGI Scripts** to manage agi scripts.

This page is a starting point for administrators: review existing records, add only the objects needed by the deployment, and keep names consistent across tenants, routing, and provisioning.

## Typical Workflow

1. Open the menu entry and confirm whether the record already exists.
2. Create or edit the record with a descriptive name and only the required options first.
3. Save the record and reopen it to verify the stored values.
4. Check dependent objects before deleting anything that may be used by routing, billing, provisioning, or reporting.

## Documentation Example

For documentation and testing, use names prefixed with **Docs Demo**. Existing PBX nodes should be reused as examples; do not create additional nodes unless the deployment actually requires them.

# System Cronjobs

Maintain system-level scheduled tasks.

Use **Admin &gt; System Cronjobs** to manage system cronjobs.

This page is a starting point for administrators: review existing records, add only the objects needed by the deployment, and keep names consistent across tenants, routing, and provisioning.

## Typical Workflow

1. Open the menu entry and confirm whether the record already exists.
2. Create or edit the record with a descriptive name and only the required options first.
3. Save the record and reopen it to verify the stored values.
4. Check dependent objects before deleting anything that may be used by routing, billing, provisioning, or reporting.

## Documentation Example

For documentation and testing, use names prefixed with **Docs Demo**. Existing PBX nodes should be reused as examples; do not create additional nodes unless the deployment actually requires them.