Building a Unified Customer View with Amazon Connect Customer Profiles
Most contact centres already hold plenty of data about their customers. The problem is that it lives in separate systems. The customer relationship management (CRM) platform knows the account history, the order management system knows what was bought, the IT service management (ITSM) tool knows the open tickets, and the telephony platform knows when the customer last called. When someone phones in, the agent sees a fraction of that picture and asks the customer to repeat information they have already given elsewhere.
Amazon Connect Customer Profiles is designed to close that gap. It consolidates data from external applications and from contact history into a single profile that an agent, or an automated experience, can read at the moment of contact. This article walks through how the service models data, how it decides which records belong to the same customer, and the architectural decisions that determine whether your unified view is trustworthy or misleading.
The focus here is the data foundation. Getting that right is what makes everything downstream, from agent screens to segmentation, actually work.
Why a unified view is harder than it looks
The appeal of a single customer view is obvious. The difficulty is that “the same customer” is a judgement, not a fact. The same person might appear as john.smith@example.com in Salesforce, a mobile number in your telephony logs, and a slightly misspelled name in a legacy order system. Merge too aggressively and you combine two different people, which is both a poor experience and a data protection risk. Merge too cautiously and the agent still sees fragments.
Customer Profiles gives you explicit control over this trade-off rather than hiding it. Understanding the model is what lets you tune that control sensibly.
Key concepts
A domain is the top-level container for your unified customer data. It holds your profiles, object type definitions, keys, encryption settings, and retention configuration, and it belongs to a single AWS account. Each Amazon Connect instance can be associated with only one domain, and domains do not share integrations or data with each other, so the domain is an important boundary to get right early.
A profile brings together the information associated with one customer. Each profile has a single standard profile object, which holds normalised fields such as FirstName, LastName, PhoneNumber, EmailAddress, and ShippingAddress, plus any number of profile objects. A profile object is a single unit of source data, for example a support ticket, a phone call, or an order record. Because the standard profile object has a fixed shape, an agent screen or an application can read it the same way regardless of whether the data originally came from Salesforce, ServiceNow, or Marketo.
It is useful to distinguish profile objects from standard objects. A profile object is the source JSON record ingested through PutProfileObject; its UNIQUE key identifies that record, and re-ingesting the same key replaces the source object. A standard object is a structured business record maintained by Customer Profiles, such as an order, case, asset, or loyalty membership. Mappings can populate fields in these standard objects without replacing the entire record. The standard profile itself is created or updated directly with CreateProfile or UpdateProfile, not by passing _profile to PutProfileObject.
The bridge between raw source data and that clean structure is the object type mapping. A mapping tells Customer Profiles how to read a specific type of record: which source fields to extract, where to write them in the standard profile, how to normalise them, and which fields act as keys. A key is a named combination of fields used to find profiles. Keys are global to the domain, so the same key name used in two mappings refers to the same logical identifier. This is what allows a Salesforce contact and a telephony contact record to resolve to the same person.
Reference architecture
A typical unified-view deployment has three layers: ingestion, resolution, and consumption.
Ingestion. Customer Profiles supports managed integrations for sources such as Salesforce, ServiceNow, Marketo, Zendesk, and Amazon S3. Depending on the source and configuration, these integrations use service-managed data flows. For custom systems, you can push records directly with the PutProfileObject API. Amazon Connect contact history uses its native Customer Profiles integration rather than requiring your application to call PutProfileObject for every contact. For historical backfills, validate the integration-specific scheduling, throughput, quotas, and failure handling before loading production data.
Resolution. As records arrive, object type mappings extract and normalise fields, and key-based matching assigns each record to a profile. Separately, Identity Resolution identifies likely duplicate profiles and can optionally merge them. These are distinct processes and should be configured and monitored independently.
Consumption. The unified profile surfaces in the agent workspace, in the newer profile explorer interface, and inside contact flows via AWS Lambda for routing and personalisation decisions.
How records become a profile
When an object is ingested, Customer Profiles decides which profile it belongs to by evaluating the keys defined in the mapping. It checks each primary PROFILE key in turn. If exactly one profile matches, the object attaches to it. If a key value points to more than one profile, that match is treated as ambiguous and discarded rather than used, which prevents a shared value such as a common household email from silently merging unrelated people. If no primary key produces an unambiguous match, Customer Profiles evaluates secondary keys marked with both PROFILE and SECONDARY. For example, an internal customer identifier might be the primary key, with an email address as a secondary fallback. Because email addresses can be shared or reassigned, use them thoughtfully rather than treating them as universally unique. If no key produces a single match, the behaviour depends on an object type property called AllowProfileCreation.
When AllowProfileCreation is true, an unmatched object creates an inferred profile, a profile built from whatever the object carried, which usually means a mostly empty standard profile with just a phone number or email populated. When it is false, the object is rejected and sent to the domain dead-letter queue. Setting it to false is the right choice when you only want to enrich customers that already exist through a separate provisioning flow, and it is an effective way to stop sparse data from accumulating thousands of thin, near-useless profiles.
Two more behaviours matter in practice. First, when several sources write to the same standard field, SourcePriority decides which value wins, with 1 as the highest priority. Treat it as your statement of which system is authoritative for each attribute. Second, by default an ingested record does not overwrite a field that an agent set manually through the agent workspace or the UpdateProfile API. That protects deliberate human corrections from being wiped out by an overnight batch load. If you genuinely want a trusted source to override manual edits, you configure SourcePriority to say so explicitly.
Identity Resolution: matching duplicates
Profile matching during ingestion relies on exact key matches. Identity Resolution handles the fuzzier problem of two profiles that clearly represent the same customer but share no exact key. Customer Profiles offers two approaches, and the choice between them is a genuine architectural decision.
Get James Wynne’s stories in your inbox
Join Medium for free to get updates from this writer.
Machine learning Identity Resolution reviews personal identifiable information (PII) across profiles, including name, email, phone number, address, and date of birth, and groups similar profiles into match groups. Each group carries a confidence score between 0 and 1, where a score near 1 indicates a likely exact match. Review match groups using the APIs appropriate to the selected matching approach before acting on them. This approach suits messy, high-variation data where you cannot easily write rules up front.
Rule-based Identity Resolution lets you define explicit matching rules, with up to 15 rule levels, each containing up to 15 profile attributes, that state which combinations of fields constitute a match. This approach suits regulated environments and cases where you need to explain and audit precisely why two profiles were considered the same.
With both approaches, start in match-only mode and inspect the results before you enable any merging. Automatic merging is powerful but, as the documentation makes clear, you cannot undo a consolidation. Where supported by your configuration, use the GetAutoMergingPreview API to inspect proposed merges. A single over-broad rule can incorrectly consolidate distinct customers, so validate representative samples before enabling merging.
Calculated attributes and segmentation
Beyond the raw profile, Customer Profiles can derive calculated attributes: aggregations computed from profile objects over a time range, such as the number of contacts in the last 30 days or total order value. These are useful inputs for routing decisions and agent context because they summarise behaviour rather than just storing facts.
For larger analytical and segmentation workloads, Customer Profiles offers a data store, a service-managed store that retains profile data updated over the past 10 years and underpins segmentation and predictive insights. It is worth being clear about its boundaries: the data store does not compute calculated attributes and does not populate the agent workspace. Those remain served by the live profile. Treat the data store as the analytical layer, not a replacement for the operational profile.
A practical example: looking up a customer profile
Consider a customer who calls about a delayed order. The CRM holds their contact details, the order system holds the purchase history, and the support platform holds an unresolved ticket. A unified profile can help an agent find the customer quickly and access associated records without asking the customer to repeat information already provided.
Once a Customer Profiles domain and its integrations are configured, a Lambda function or other authorised application can use Boto3 to search for a profile by email address:
import boto3
client = boto3.client("customer-profiles")
response = client.search_profiles(
DomainName="customer-domain", # Replace with your domain name
KeyName="_email",
Values=["john.smith@example.com"],
MaxResults=10,
)
for profile in response.get("Items", []):
print("Profile ID:", profile["ProfileId"])
print("Name:", profile.get("FirstName"), profile.get("LastName"))
print("Email:", profile.get("EmailAddress"))The _email search key is a standard profile index. This example is deliberately read-only and assumes that the domain exists, the profile is populated, and the caller has permission to use SearchProfiles. It is not an identity-verification step: an email address alone may be shared or stale. In production, handle pagination, ambiguous matches, API failures, and access controls. Related orders or cases may require separate queries for associated objects; a profile search does not automatically return every linked source record.
Security, operations, and cost considerations
Encryption and data protection. A domain has its own encryption configuration, and because profiles hold PII by definition, key ownership and access to the domain deserve careful review. Scope AWS Identity and Access Management (IAM) permissions for ingestion and read APIs to the minimum each component needs, and separate ingestion roles from agent-facing read roles. Avoid logging raw profile payloads or customer identifiers unnecessarily, and review encryption, access auditing, and PII handling against your organisation’s requirements.
Retention. Retention is configured per domain. Set it deliberately rather than accepting a default, both to control cost and to meet data protection obligations such as the General Data Protection Regulation (GDPR). Holding PII longer than you need is a liability, not an asset.
Failure behaviour. Objects that cannot be matched when creation is disabled go to the domain dead-letter queue. Monitor that queue, together with ingestion job status, integration failures, and Lambda errors. Define alerts, replay procedures, and ownership for records that fail ingestion. A growing dead-letter queue can signal a mapping or key problem, such as a source that stopped sending the field you match on, and it is the clearest early warning that your unified view is quietly drifting out of date.
Cost drivers. The main drivers are the volume of profiles and objects you ingest, Identity Resolution processing, and any data store and segmentation usage. Historical backfills can generate a large one-off ingestion spike because of the automatic multi-flow behaviour, so plan the initial load rather than letting it run unbounded. Confirm current figures on the official Amazon Connect pricing page before you commit to a design, as pricing changes over time.
Common mistakes
Common failures are often caused by rushed design decisions rather than service faults. Enabling automatic merging before reviewing match results tops the list. Close behind is leaving AllowProfileCreation on for every source, which floods the domain with inferred profiles built from a single stray email. Neglecting SourcePriority is another, which leaves conflicting values resolving unpredictably rather than by a rule you chose. Finally, teams often forget that moving an Amazon Connect instance to a different domain does not carry the existing profiles across, so the move silently resets the unified view.
Production design checklist
Before enabling a new integration, confirm the authoritative source for each customer attribute, the keys used for matching, and whether the source may create inferred profiles. Test shared emails, changed phone numbers, duplicate records, and missing identifiers. Review Identity Resolution matches before enabling irreversible merges. Finally, verify least-privilege access, retention, operational alerts, and a process for correcting incorrectly linked records.
Conclusion
A unified customer view is a data engineering problem wearing a customer experience badge. Amazon Connect Customer Profiles gives you the building blocks, domains, object type mappings, keys, and two styles of Identity Resolution, but the quality of the result depends on the decisions you make about matching, creation, and source priority.
A practical starting point is to bring in two or three high-value sources, define keys carefully, leave AllowProfileCreation off for sources that should only enrich existing customers, and run Identity Resolution in match-only mode until you trust the groupings. Expand from there once the foundation is sound. Get the matching right first, and the agent screens, segments, and automation built on top of it will be worth trusting.
