View a markdown version of this page

Profile matching and inferred profiles in Customer Profiles - Amazon Connect Customer
How a profile is matchedControlling profile creation with AllowProfileCreationInferred profilesMerging behavior and source priorityManual updates are protected by default

Profile matching and inferred profiles in Customer Profiles

This topic explains how Connect Customer Customer Profiles decides which profile an ingested object belongs to, when it creates a new profile, and how it protects manually entered data. For the end-to-end ingestion flow, see How object type mapping works in Customer Profiles.

How a profile is matched

An ingested object is validated and queued, and profile matching happens shortly afterward. Matching follows this order:

  1. Customer Profiles evaluates each primary PROFILE key:

    • If exactly one profile matches, the object is attached to that profile.

    • If more than one profile matches, the match is ambiguous—that key is discarded and the next is tried.

    • If no profile matches, the next key is tried.

  2. If no primary PROFILE key produces an unambiguous match, Customer Profiles repeats the process with any secondary keys (keys whose standard identifiers include both PROFILE and SECONDARY).

  3. If no key produces a single match, the outcome depends on AllowProfileCreation (see Controlling profile creation with AllowProfileCreation).

Note

An ambiguous match—a key value that points to more than one profile—is never used to attach an object. This prevents a shared value, such as a common email address, from silently merging unrelated profiles.

Controlling profile creation with AllowProfileCreation

AllowProfileCreation is a property of the object type that controls what happens when no profile matches:

  • true: a new inferred profile is created and the object is attached to it.

  • false: the object is rejected and sent to the domain dead-letter queue. Use this when you only want to enrich profiles that already exist, for example because they're created through a separate provisioning flow.

When you create an object type from a template, the template's AllowProfileCreation value is used and can't be overridden on the request.

Inferred profiles

An inferred profile is a profile that Customer Profiles creates automatically when an ingested object can't be matched to any existing profile. Because the source object usually doesn't carry a full customer record, the standard profile object on an inferred profile starts mostly empty.

What gets populated on an inferred profile

When an inferred profile is created, the standard profile object is initialized from the fields in the object type mapping. Fields that define a Target are populated as usual. Two fields are also populated automatically, even when the field defines no Target:

  • A field with ContentType of EMAIL_ADDRESS populates _profile.EmailAddress.

  • A field with ContentType of PHONE_NUMBER populates _profile.PhoneNumber.

Note

This automatic population happens only when an inferred profile is created, and it writes to the standard profile fields _profile.EmailAddress and _profile.PhoneNumber—not to the _email and _phone search keys. When an object matches an existing profile, a ContentType on its own writes nothing; only fields with a Target update the standard profile.

Avoiding unwanted inferred profiles

With inferred profiles, you can keep ingesting data even when the customer isn't already known, but they can accumulate when source data is sparse. To control this:

Merging behavior and source priority

When an object matches an existing profile, its Target fields update the standard profile object. When multiple object types map to the same standard field—for example, both a Salesforce and a Marketo mapping populate _profile.EmailAddress—SourcePriority determines which value wins. SourcePriority is an integer where 1 is the highest priority—object types with lower values take precedence. An object type without a SourcePriority defaults to the lowest priority.

Manual updates are protected by default

Note

By default, an ingested object that matches an existing profile doesn't overwrite fields populated manually through the UpdateProfile API or the Connect Customer agent workspace. This protects intentional changes from being silently replaced by automated ingestion. Use SourcePriority when you do want a trusted ingestion source to take precedence over manual updates.

For example, suppose an agent creates a profile with FirstName set to John. Later, an object that maps to _profile.FirstName is ingested and matched to that profile. If the ingesting object type has no SourcePriority configured, the FirstName value remains John—the ingested value is stored on the profile object but doesn't replace the manually set standard field. If you configure SourcePriority to rank that object type above manual updates, the ingested value replaces John instead.