Campaigns

A campaign represents a business programme, bundle, promotion, or allowance scheme owned by an entity. It provides the parent record for one or more Campaign Classes. A service limit can use those classes to decide how much data an identified user may consume.

Campaigns do not apply a limit by themselves. Think of the configuration in this order:

1. The Campaign identifies the programme and owning entity.
2. Campaign Classes define the allowance tiers within that programme.
3. A Service Limit links the campaign to a service and reads the user identifier from a request header.

Example

An entity offers a sponsored-data campaign called Student Learning 2026. The campaign has two classes:

• standard — 250 MB per day and 2 GB per month;
• premium — 1 GB per day and 10 GB per month.

The service limit attached to the learning service imports these classes. Requests must contain the user-identification information expected by that service limit so that usage is counted against the correct user and campaign class.

Campaigns list

Open Gateway > Campaigns to view the campaigns available to your role. The list can be searched, filtered, or displayed as a list or grid. Use the campaign name, entity, identifier, and state to confirm that you have selected the correct record before editing it.

Before you create a campaign

Confirm the following with the campaign or product owner:

• which entity owns the campaign;
• the user-facing name;
• a stable technical identifier;
• whether it should be active immediately;
• the required allowance classes and their daily and monthly values; and
• which services will enforce those allowances.

Using an agreed naming convention makes campaigns easier to find. For example, include a programme and year in the display name, while keeping the identifier short and stable.

Create a campaign

1. Open Gateway > Campaigns.
2. Select Create Campaign.
3. Enter a unique Name.
4. Select the owning Entity.
5. Enter the technical Identifier.
6. Select the Campaign State.
7. Review the values and select Create Campaign.
8. Confirm that the new campaign appears in the list.

Field guide

Field	Required	What it controls	Guidance
Name	Yes	The display name shown in the portal.	Use a recognisable, unique name. The portal allows up to 80 characters.
Entity	Yes	The entity that owns the campaign.	This determines the campaign's business scope; it is not only a reporting label.
Identifier	Yes	The stable technical identifier used by related configuration.	Use letters, numbers, and dashes only. Spaces and underscores are not accepted. Avoid changing it after integration.
Campaign State	Yes	Whether the campaign is active or inactive.	Keep draft, expired, or suspended campaigns inactive until they are approved for use.

Important

The campaign's database ID and the Identifier shown to users are different concepts. Select campaigns by name in the portal, but keep the visible identifier stable because downstream request and limit configuration may depend on it.

Configure the campaign classes

After creating the campaign, create at least one active campaign class. Each class supplies:

• a class identifier;
• a unit of measure;
• a daily allowance;
• a monthly allowance; and
• an active/inactive state.

When Limit By is set to service_and_user on a service limit, selecting a campaign loads that campaign's active classes into the limit configuration. A campaign with no usable classes cannot provide the intended user allowances.

Activate safely

A safe rollout is:

1. Create the campaign as inactive.
2. Add and review its campaign classes.
3. Create the service limit with Enabled switched off.
4. Test the service's user-identification header and class selection in a non-production environment.
5. Activate the campaign/classes and enable the service limit according to the approved change plan.
6. Monitor threshold notifications and gateway responses after release.

Edit or retire a campaign

Open the campaign from the list, make the change, and select Update Campaign.

Before changing the entity, identifier, or state, check the campaign's classes and all service limits that use it. Changing a technical identifier without updating callers can prevent traffic from being associated with the intended allowance. Changing ownership can also make the campaign appear in a different business scope.

To retire a campaign, first disable or replace related service limits, then set the campaign and its classes to inactive. Keeping the records is normally safer than deleting configuration that may be needed for audit or historical reporting.

Troubleshooting

The campaign is not available in a service limit

• Confirm that the campaign was saved successfully.
• Confirm that it has at least one active campaign class with a daily or monthly allowance.
• Check whether your role can access the campaign's entity.
• Refresh the page after creating or updating the classes.

Usage is assigned to the wrong campaign or class

• Check the campaign and class identifiers for spelling and case.
• Check the service limit's selected campaign.
• Confirm the calling application sends the expected user identifier header.
• Verify that the user-to-class value used by the integration matches an active class identifier.

A campaign should no longer be used

Do not delete it immediately. Disable the enforcing service limit or migrate it to the replacement campaign, set the old classes and campaign inactive, then confirm that no live traffic depends on them.