One Customer Timeline Across Sales, Service and Marketing When the Systems Are Siloed

Why can agents not see the full customer history today?

Because each system records its own slice of the relationship and nothing joins them. Sales activity sits in the CRM, complaints and cases in a service tool, campaign responses in a marketing platform, orders or contracts in a legacy line-of-business system. Each has its own customer identifier, and the agent is expected to search all of them by name while the customer waits.

The visible symptoms are familiar: a complaint handled without knowing an order failed last week, a renewal call made in the middle of an open escalation, a marketing email sent to someone who asked to stop in a service call. Reports built across the systems disagree because each counts a different version of the customer. The fix is not another screen per system; it is one ordered history per customer that every channel writes into. If the problem is mainly that agents juggle many applications, composing one agent surface over them is covered in our guide to agent desktop unification. This page is about the history itself.

Should you copy interaction data into Dataverse or read it live from each system?

Read live when the source has a usable API with predictable latency, the data changes constantly, and you only need it on one form. Copy when the history must be fast, sortable across sources, reportable, and available when a source is down. A customer timeline almost always needs the second set of properties, and a legacy system with a broken API rules out the first.

Virtual tables are the live option in Dataverse. They present external data as a table in views, lookups and subgrids without copying it, through an OData v4 endpoint, one of the virtual connector providers, or a custom data provider you write. They are a good fit for a clean, well-indexed source. Every read goes to the source at query time, so the source latency becomes the form latency, and a source that times out or pages inconsistently produces an empty or partial timeline in front of the agent. Check current Microsoft documentation for which providers and capabilities are supported before planning on one.

What should the interaction-event table look like?

Keep it thin. The event table is an index of what happened to a customer, not a second copy of every source system. Each row says which system, which record, what kind of event, when, for which customer, a short human summary, and where to click to see the detail. Full order lines, email bodies and call recordings stay in their systems.

The decision to make first is whether the table is an activity table. A custom table created as an activity table (a name such as Interaction Event) behaves like email, phone call and task: it has a Regarding lookup, participates in activity views, and can appear in the timeline control on contact and account forms alongside native activities. The activity setting has to be chosen when the table is created; it cannot be switched on later, so decide before the first solution import. If you create a regular table instead, it is usually shown as a related subgrid or a custom control beside the timeline rather than inside it. Verify the current timeline configuration options in Microsoft documentation, because they change with release waves.

How do adapters get events from each source into the table?

One adapter per source, each owning only the translation from that source into the event shape. Adapters never talk to each other, and a failing adapter stops only its own source. Every adapter writes with an upsert on the source system plus source record ID key, so replaying a day of events is safe.

For sources with a working API or change feed, a Power Automate cloud flow is often enough at modest volume, and Azure Functions or Logic Apps suit higher volume or heavier transformation. How we engineer flows with retries, error paths and service accounts is on our Power Automate consulting page. Where adapters need an outbox, backoff and dead-lettering, follow the patterns in point-to-point integration rationalisation rather than inventing new ones.

• API or webhook source: subscribe to events where the source can push, poll with a watermark where it cannot, and map each record to one or more event rows.
• Source with a broken or no usable API: read what it can produce reliably. A scheduled export file dropped to a monitored folder, or a read-only query against its database or reporting replica through the on-premises data gateway, is usually more dependable than a half-working API.
• Source with no export and no database access: a desktop flow reading screens is a last resort for low volume, with alerting, because screen changes break it silently.
• Every adapter records a run log: rows read, rows upserted, rows rejected and why, so silence is detectable.
• Backfill history once with the same adapter logic in bulk, then switch to incremental. Loading at volume is covered in our Dataverse bulk import guide.

How do you match events from different systems to the right customer?

Resolve identity at capture, once, deterministically, and never let the timeline guess. The adapter looks up the customer when it writes the event, using identifiers that cannot be ambiguous, and stores the result as the customer lookup. Fuzzy name matching at read time is how a complaint ends up on the wrong customer's history.

Hold a cross-reference table in Dataverse of external identifiers per customer: source system, external ID and the contact or account it belongs to. The adapter's first step is a lookup on that table. Deduplicate contacts and accounts before you start, because duplicates break resolution before any code does; our duplicate data cleanup guide covers the method. For marketing-led unification of profiles across many sources, Customer Insights - Data has its own identity resolution, described on our Customer Insights page.

• Match rule order: an existing cross-reference entry first, then exact matches on strong identifiers such as customer number, registration or VAT number, then a normalised email address. Stop at the first single match.
• Several candidates or none: write the event with no customer and put it on an unmatched queue for a person to resolve, rather than attaching it to the most likely record.
• When a person resolves an item, create the cross-reference entry, so the next event from that external ID matches automatically.
• When two contacts are merged, repoint the cross-reference entries and the events, and keep a log of the change.
• Monitor the unmatched queue size per source. A growing queue means a match rule or a source identifier has changed.

How does the timeline control show events from other systems?

With an activity table, events appear in the timeline on the contact or account form in date order next to emails, calls and notes, filtered by activity type like any other activity. Configure the timeline to include the new type, give the rows a clear subject line built from the summary, and make the deep link one click from the record. Check how your environment rolls up activities from related records, for example contact activities on the parent account, because that behaviour is configurable and has changed over releases.

Keep the timeline fast: index the customer lookup and occurred-on columns through normal Dataverse practice, show a sensible default date range, and archive or summarise very old events instead of loading decades of rows on every form open. Security applies as normal, so an agent sees only the event rows their role allows; decide at design time whether sensitive event types need their own ownership or column security. The Customer Service side of the agent experience is scoped on our Dynamics 365 Customer Service page.

How do you build a Power BI single customer view over the same data?

Report from the same event table and cross-reference, not from a separate integration. That way the agent's timeline and the board's Customer 360 count the same events for the same customers, and a disagreement means a data problem you can trace, not two pipelines with different rules.

Model the event table as a fact with customer, event type, source system and date dimensions. For anything beyond small volumes, report from an analytical copy of Dataverse, such as Azure Synapse Link for Dataverse or Link to Microsoft Fabric, rather than querying the transactional store directly; the reasons and the options are in our guide to Dynamics 365 reporting limits. Put the unmatched queue on the dashboard too. A Customer 360 that hides how many events could not be attributed will be trusted until the first time it is wrong.

How can you demo a Customer 360 to the board within a month?

By cutting scope, not corners. The first month proves the pattern end to end on a slice small enough to finish, and leaves the design unchanged for the next sources. Promise the board a working, read-only history for real customers, not a finished platform.

Is Dataverse the right home for a unified customer history?

Usually, if your agents already work in Dynamics 365 or a model-driven app, because the timeline, security model and reporting routes are already there and the event table is a small addition. It is a weaker fit if no team works in Dynamics 365 and the only goal is analytics, in which case the events can land directly in an analytical store, or if licensing for the users who need the history does not fit.

We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both. Where Microsoft licensing does not suit the people who need the history, a custom-built CRM on React, Node.js, PostgreSQL or .NET can hold the same event model, adapters and identity rules under your own control.

How does Solzet help unify customer history across siloed systems?

We start with the two sources and the customer segment that matter most, agree the event types and match rules with the people who will rely on them, and build the event table, cross-reference, adapters, timeline configuration and Power BI view in that order. Every adapter is idempotent and logged, the unmatched queue has an owner, and the design is written down so your team can add the next source without us.

Solzet delivers remotely from Yerevan, Armenia, with senior consultants and full-stack developers and 8+ years of Dynamics 365 Customer Engagement and Power Platform work, directly or white-label for Microsoft partners.