Microsoft Entra ID Extension Attributes

Quick Answer

Pinnacle Series can synchronize custom Microsoft Entra ID attributes, including directory extension attributes such as extension_{appId}_*, without a code change, as long as the attribute exists in Entra ID and is mapped in Pinnacle Series or referenced in a Rule Set. Schema extensions and custom security attributes are not supported.

What This Article Helps With

This article is for Pinnacle Series Administrators who want to understand which Microsoft Entra ID extension attributes Pinnacle Series can read, how Pinnacle Series builds its Microsoft Graph query, how to map a new extension attribute, and how to avoid common configuration pitfalls.

Supported Extension Attribute Types

Pinnacle Series supports directory extension attributes (simple key/value pairs) and standard Entra ID user fields. Schema extensions and custom security attributes are not supported.

Examples of supported attributes:

extension_{appId}_employeeType = Contractor
extension_{appId}_region = EMEA
department = Civil

We recommend standardizing on directory extension attributes that behave like simple key/value pairs (single text values). These are the most reliable attribute type for automated Group provisioning, assignment targeting, and reporting.

How Pinnacle Series Builds the Microsoft Graph Query

When Pinnacle Series calls the Microsoft Graph /users endpoint, the list of selected fields is built from your tenant configuration. The following are included in the Graph $select:

The email attribute configured in your Entra ID sync settings (for example, mail).
The display name attribute configured in your Entra ID sync settings (for example, displayName).
All fields mapped under Map User Attributes.
All attribute names referenced in Rule Sets, if not already included.

If a custom attribute is not mapped under Map User Attributes or referenced in a Rule Set, Pinnacle Series may not include it in the Graph query and will not retrieve it. The mapping configuration determines which attributes Pinnacle Series retrieves from Microsoft Graph.

Mapping a New Extension Attribute

Confirm the attribute exists in Entra ID. For example, extension_{appId}_employeeType.
Confirm the attribute is populated on user objects, using consistent, human-readable values (for example, Employee, Contractor, or Consultant).
Map the attribute in Pinnacle Series: go to Administrator Portal > Integrations > Entra ID Configuration > Map User Attributes.
Optionally, reference the attribute in a Rule Set for automated Group provisioning. For example: employeeType = Contractor → assign to the "Contractors" Group.
Validate the configuration with a small pilot group before scaling. Confirm that the attribute appears on synced users and that any Rule Sets referencing it behave as intended.

Naming and Formatting Rules for Extension Attributes

Use attribute names that are clear, stable, and easy to interpret across teams.

Recommended patterns:

extension_{appId}_employeeType
extension_{appId}_region
onPremisesExtensionAttributes.extensionAttribute1
{AttributeName}.{FieldName}, only when needed for object-based attributes.

Avoid:

Ambiguous names, such as custom1 or miscField.
Attributes that store arrays or variable nested objects.
Inconsistent values, such as "Contractor," "contractor," "Ctr," and "External" used interchangeably.

Common Pitfalls and Fixes

If an extension attribute does not display in Pinnacle Series, check the following in order: mapping, population, then format. Most failures come from one of these three.

Pitfall	Fix
The attribute exists in Entra ID but is not mapped in Pinnacle Series.	Add it to Map User Attributes, or reference it in a Rule Set, so that it is included in the Graph $select.
The attribute is mapped, but values are blank for many users.	Validate your Entra ID population rules and confirm the value is set on real user objects, not only in theory.
A complex object attribute is used without specifying a field.	Use {AttributeName}.{FieldName}, for example extension_{appId}_employmentInfo.employmentType.
Inconsistent values break Rule Sets and reporting filters.	Standardize a controlled vocabulary (for example, Employee, Contractor, Consultant) and enforce it across all source systems.

Helpful Tips

If you need consistent Rule Sets and clean reporting, prefer simple text-like attributes (single value) over complex object attributes.
Standardizing on simple text-like attributes gives you the most predictable input for Group rules, assignment automation, and reporting filters.