Granular Delegation
Overview
Granular delegation extends the existing Share Access methods — Delegation and OAuth App — with feature-level access control. an organization can now choose:
- Which features to delegate to a partner (for example, location management only, or brand only)
- Which brands those features apply to
This allows organizations to engage specialized partners — one managing location data, another managing brand identity — without either partner having access to features outside their scope.
Current Delegation Model
Today, both Share Access methods grant a partner access to the full set of manageable features for an authorized brand. They differ, however, in brand scope:
| Method: OAuth App | Method: Delegation | |
|---|---|---|
| Brand scope | All current and future brands (organization-wide) | One brand, a subset, all current, or all current and future |
| Feature scope | All features | All features |
| Create brands on behalf of organization | Yes | No |
| Delete brands on behalf of organization | No | No |
The key limitation with OAuth is brand scope: authorizing a partner via OAuth grants them access to every brand the organization owns, now and in the future. Delegation already supports brand-level scope.
What Changes with Granular Delegation
Granular delegation makes two changes that affect both methods:
1. Feature selection. When setting up a delegation, the organization selects which features to include. A partner authorized for locations cannot access brand identity features, and vice versa. This applies to both OAuth and delegation.
2. OAuth gains brand-level scope. The OAuth authorization flow is updated to include brand selection. An organization can now authorize an OAuth partner for specific brands — not just all brands organization-wide. This brings OAuth into parity with what delegation already supports.
The goal is full parity between the two methods: the same feature and brand scope options are available regardless of which delegation method is used.
Delegatable Features
The following features can be delegated under granular delegation.
| Feature | Availability | Requires Apple Approval | Exclusive per Brand |
|---|---|---|---|
| Brands | Initial launch | No | No |
| Locations | Initial launch | No | No |
| Ads on Maps | Initial launch | No | No |
| Business Caller ID (BCID) | Initial launch | Yes | Yes — one agency per brand |
| Branded Mail | Future release | Yes | TBD |
Features listed as future releases will not be available at initial launch. The delegation model is designed to accommodate additional features over time.
Feature Constraints
Country Availability
A feature cannot be delegated for a brand if that feature is not available in the brand's country. Eligibility is determined by the brand's country, not the organization's country.
Feature Exclusivity
Most features are non-exclusive — the same feature can be delegated to multiple partners for the same brand. In this case, each partner can update data contributed by the other. Managing potential conflicts between partners is the responsibility of the owner organization.
BCID is exclusive. A brand's BCID feature can only be delegated to a single approved agency at a time. An organization may delegate BCID for each of its brands to a different agency, but cannot delegate the same brand's BCID to two agencies simultaneously.
Brand Create
Under granular delegation, whether a partner can create brands on behalf of an organization depends on both brand scope and feature:
Create brand is permitted when:
- The delegation covers all current and future brands, and
- The delegated feature includes brand creation permissions
A partner authorized for a subset of brands (not "all current & future") cannot create a new brand on behalf of the organization.
BCID-Specific Constraints
- BCID cannot be delegated for all current and future brands. It must be assigned to specific brands individually.
- At initial launch, a BCID-approved agency cannot simultaneously be delegated other features for the same brand.
Delegation Method Behavior
The table below summarizes the key behavioral differences between OAuth and delegation, before and after granular delegation.
| Capability | OAuth — Today | OAuth — Granular | Delegation — Today | Delegation — Granular |
|---|---|---|---|---|
| Brand scope | All current & future brands only | One brand, subset, all current, or all current & future | One brand, subset, all current, or all current & future | Unchanged |
| Feature scope | All features | Selected feature(s) | All features | Selected feature(s) |
| Create brand | Yes | Yes, when Brand scope is all current and future brands | No | Yes, when Brand scope is all current and future brands with appropriate feature |
| Delete brand | No | No | No | No |
Changes to the OAuth Authorization Flow
The OAuth flow is updated to include feature and brand selection steps:
- Organization authorizes the partner's OAuth app connection.
- Organization selects which feature(s) to delegate to the partner.
- Organization selects which brand(s) those features apply to.
This replaces the current behavior where authorization automatically grants the partner access to all brands and all features.
Partners may need to update their OAuth applications to support granular delegation. If an organization authorizes a partner for specific features only, the partner's application should respect that scope and not attempt to manage features outside the delegation.
Migrating Existing Connections
OAuth Connections
Existing OAuth connections are migrated based on feature type:
Automatically migrated (Brand and Locations): Existing connections are automatically updated to include Brand and Locations feature scope. The organization's access token remains valid; no action is required from the organization or the OAuth partner for these features.
Requires explicit action (BCID and Branded Mail): These features require explicit owner selection and cannot be automatically migrated. If a partner manages these features, the organization must re-authorize the connection after granular delegation launches — typically by going through the OAuth authorization flow on the partner's platform again. After re-authorization, the partner receives a new access token scoped to the explicitly selected features. The prior access token will not include BCID or Branded Mail scope.
Delegation Connections
Existing delegations are automatically migrated and do not require the owner organization to take action. The delegated partner's service account credentials are not affected.
However, partners should update their integrations to expect feature-scoped responses. After migration, API calls for features outside the delegation's scope will return HTTP 403. Partners relying on broad access should audit which features are included in their migrated delegations and adjust their integrations accordingly.
Agency Feature Approval
Some features require Apple to approve an agency before an organization can delegate that feature to them. The delegation flow will only display features that the selected agency is approved for.
At initial launch, all verified agencies are automatically approved for Brands and Locations. Features requiring explicit Apple approval are noted in the feature table above.
If an agency's approval for a feature is revoked:
- Each owner organization that had delegated that feature to the agency will be notified.
- The agency will also be notified.