What it does

Activities turn rows in transactional tables — orders, cases, web visits, subscription events, survey responses — into dated events hung off a unified customer profile, and render them as a single chronological timeline on the profile page. They are also what makes time-based measures and behavioural segments possible.

Key facts

• An activity table needs a date or datetime field and a primary key that is unique, non-null and stable across refreshes. Unstable keys produce duplicate timeline entries.
• Configuration is a four-step wizard per table: pick the table and primary key, map the activity fields, define the relationship to a customer table, then review and create.
• The field mapping covers activity name, timestamp (the event start), event activity, and optionally web address and additional detail. A Show in timeline toggle controls whether the activity is rendered on the profile at all.
• Activities attach to profiles through a relationship — a foreign key on the activity table pointing at a table used in unification. Relationship names are case-sensitive, and inherited relationships cannot be used for activities. You need a system or custom relationship.
• Semantic types available out of the box are Feedback, Loyalty, SalesOrder, SalesOrderLine, Subscription, plus Other for non-semantic activities and Custom for your own type. Intelligent mapping will predict the semantic field mapping for you.
• SalesOrderLine and Quotes are not shown on the timeline unless timeline display is explicitly turned on, and web personalisation activities are not shown at all.
• An activity only reaches the timeline if it is configured with show-in-timeline set to yes, has a valid timestamp, is mapped to a supported activity type, and has actually been unified and matched to a profile.
• Timeline filters exist for activity type and date, but they reset the moment you leave the profile. There is no persisted per-user view.
• The same activity data can be surfaced inside model-driven apps through the Customer Insights timeline integration or the Customer Card add-in solution.
• Activities are also exposed via the APIs, so a portal or contact centre screen can render the same history without going through the CI UI.

When to use / skip

Configure activities on any project where somebody is going to open a customer profile and ask "what has this person done with us?". That is nearly all of them. It is also a prerequisite for the interesting half of the measure and segment catalogue — recency, frequency, days-since-last-order, churn-style behaviour — so if the roadmap includes any of that, activities are not optional.

Skip, or defer, when the client's only near-term goal is list building for an email tool off demographic attributes, and the transactional data is not yet clean or complete. A timeline half-populated with orders from one of three source systems does more reputational damage than no timeline at all. Better to ship without it and add it once the data sources are in.

Configuration decisions

• Which tables become activities. Every candidate has a cost in unification runtime, so choose the ones that answer real questions rather than mapping everything transactional.
• The semantic type per table, including whether to define a custom type. Semantic type drives the icon, the layout of the timeline entry, and what downstream features recognise the data.
• Which timestamp field represents the event. Order date, ship date, invoice date and created date are all defensible and all give a different timeline. Agree it with the business, not with the DBA.
• The relationship path from activity to unified profile, and whether the existing system relationships suffice or you need a custom one through a bridge table.
• What goes in the additional-detail and web-address fields — this is the only free-text real estate you get per entry, so it should carry the value or reference a user actually needs.
• Whether granular tables such as order lines belong on the timeline or should stay off it and feed measures only.

Gotchas

• Activities that fail to resolve to a profile do not raise an obvious error. They simply never appear. Always sanity-check counts against source after the first run.
• An unstable primary key — a hash including a last-modified date, say — means every refresh looks like new activity, and the timeline fills with duplicates.
• Relationship names are case-sensitive. PurchasesToContacts and purchasesToContacts are different, and the mismatch is easy to make when someone recreates a relationship by hand.
• Inherited relationships, the ones created automatically at ingestion, cannot be used here. If that is all you have between activity table and customer table, you need to create a custom relationship first.
• Very high-volume activity tables — clickstream, IoT-style telemetry — will make the timeline unusable and stretch refresh times. Aggregate upstream rather than mapping raw events.
• Timezone handling comes from the source data. If some systems store UTC and others local time, the merged timeline will be subtly wrong and nobody will notice until a support call about ordering.

Consultant notes

• Demo the timeline early. It is the single most persuasive screen in the product for service and sales stakeholders, and it is what gets budget signed off for the boring unification work behind it.
• Agree the definition of each activity's timestamp in writing during design. "Which date is this?" is the most common post-go-live challenge to the timeline's credibility.
• Check the show-in-timeline flags before go-live. Teams frequently map a table for measure purposes, leave the toggle off, and then field complaints that the data is missing from the profile.
• If the client already lives in a model-driven app, plan for the timeline integration or Customer Card add-in rather than expecting agents to switch to the CI UI. Adoption depends on it.
• Push back on mapping every transactional table on day one. Three well-chosen activity types beat a dozen noisy ones, and you can always add more.

---

Worth another look if the semantic type list grows, or if timeline rendering of high-volume activity tables improves.