The Global Address Book in Dynamics 365 Finance & Operations

A single individual or organisation might be a customer for one legal entity, a vendor for another, a business contact in CRM-style scenarios, and the employer of internal workers. Without a unifying model, the same party gets recorded multiple times with slight variations, and analytics lose coherence. F&O's Global Address Book (GAB) is the cross-legal-entity store that holds parties once and assigns them roles.

Core entity: Party. A party in GAB is a person or organisation. Each party has:

• Type — Person or Organisation.
• Name and address details.
• Contact information — phone, email, URLs.
• Identification numbers — VAT registration, DUNS, government IDs.
• One or more roles — Customer, Vendor, Contact, Worker, Competitor, Other.

A party can hold multiple roles simultaneously: organisation Acme Corp is a Customer in three legal entities and a Vendor in one. Each role is a separate record in the role-specific table (Customer, Vendor) but linked back to the same party.

Why this matters. Reconciling "who's who" across customer master, vendor master, and worker records becomes one query — joining through the party. Master data quality programs operate at party level; data quality fixes propagate to all roles.

Cross-legal-entity sharing. GAB is enterprise-wide — one address book across all legal entities in the F&O tenant. A customer created in Legal Entity A can be activated as a customer in Legal Entity B by adding the customer role for that entity, reusing the underlying party.

This is a structural advantage F&O has over many ERPs: one global identity, locally activated as needed.

Address book hierarchy. The hierarchy:

• Default global address book — the single shared book.
• Custom address books — optional sub-books for specific scopes (e.g. "Legal" address book for in-house counsel use).

Most installations use only the default book. Custom books are for unusual segregation requirements.

Addresses on parties. Each party can have multiple postal addresses, each with:

• Purposes — Invoice, Delivery, Statement, Statutory, Multiple.
• Effective from/to dates — addresses can age in/out.
• Primary flag — designates the default for a purpose.

When a customer record is created, addresses are derived from the party's address book entries — but can be overridden at customer level if needed for that legal entity's relationship.

Names and translations. A party may have:

• Primary name — the canonical name.
• Translations — alternative-script names (Chinese, Arabic) for global vendors.
• Alternative names — DBA, "trading as", historical names.

Search across all name variants is supported, useful for finding an organisation whose name has shifted over time.

Contact persons. A contact in GAB is a person party linked to an organisation party via a role. This person is "the buyer at Acme" but also exists as a party in their own right — they could later become a vendor contact at a different organisation. Maintaining contacts at party level rather than per-customer-per-LE prevents duplicate contact records.

Workers and HR. Internal employees are also parties. The worker party is linked to an HR worker record (in the HR module) or a project worker (in Project Operations). Same person, different roles.

Duplicate detection. Adding a new party with a name similar to an existing party triggers duplicate warnings. The match algorithm uses name similarity, address proximity, and identifier overlap. Manual review confirms or rejects the duplicate.

Merge. If two parties turn out to be the same:

• Merge function moves all role assignments to one surviving party.
• Transactions, addresses, contacts all redirect.
• The merged-away party is marked inactive but retained for audit history.

Use with care — merge is hard to undo.

Integration with Dataverse and CDS. When F&O integrates with the Power Platform via Dual-Write, the GAB party model maps to Dataverse's Account and Contact tables. The party identifier becomes a key bridging both sides. This dual-write is the underlying plumbing for the unified "Dynamics 365" experience.

Common pitfalls.

• Creating duplicates in workflow. Sales rep creates a customer without checking if the party already exists; duplicate party emerges; reconciliation later is painful.
• Address divergence. Addresses overridden at customer level drift from the party master; cross-LE reporting shows different addresses.
• Forgotten role activation. A customer exists in LE A; LE B starts trading with the same customer but creates a new party instead of activating the existing one.
• GAB performance at scale. Very large GAB (millions of parties) can slow address book lookup; index tuning and archiving stale parties helps.
• Merge ambiguity. Merging two parties where one has high-value historical data; merge logic preserves the surviving party's data — picking the wrong survivor loses history.

Operational disciplines.

• Master data ownership — a single team owns party creation across all LEs, with workflow approval and duplicate-check enforcement.
• Periodic dedupe runs — duplicate detection runs against the full GAB, flagging probable duplicates for review.
• Identifier governance — VAT numbers, DUNS, government IDs collected and used as primary match keys.

The unifying value. GAB is one of F&O's more architecturally interesting features — a global identity model that few competitors match. The implementation upside (data quality, cross-LE analytics, integration simplicity) only materialises with master data discipline; without it, GAB becomes another store of duplicates.