Oct 2026: Tenant Engagement CMS - Store history now gives you a clearer audit trail for profile changes

What it is and why it matters for Tenant Engagement

The CMS now records key store-level changes against individual profiles, including when somebody is:

• added to a store;

• removed from a store;

• promoted to a different role; or

• demoted to a different role.

Previously, the CMS provided centre-level status history, but changes to a person's individual store membership or role were not presented in the same way.

The new Store History provides a more complete audit trail, making it easier for property teams to understand what changed, when it changed and who made the change.

This can be particularly valuable when investigating access questions, reviewing changes to store teams or understanding why a person currently has a particular role.

When to use this

Use Store History when you need to understand how a person's relationship with a store has changed over time.

For example, it can help when:

• checking when somebody joined or left a store;
• confirming when a person's role changed;
• investigating unexpected access or permissions;
• reviewing changes made by other administrators; or
• answering questions about how a profile reached its current state.
  
  
  

How it works (high-level)

In the CMS, open the relevant person's profile from People > All People.

Alongside the existing profile history information, you can now view a separate Store History showing relevant store-level changes.

Each entry includes information such as:

• the action that took place;
• the relevant store and role;
• who made the change; and
• when the change was made.

Changes made through supported Kinexio services are recorded in the same history, helping provide a more consistent view regardless of where the original update was made.

Existing store membership information has also been incorporated so teams are not starting with an empty history following the release.

Best practice tips

• Check Store History before making corrective changes to a profile, as it may explain why the current configuration exists.
• Use the history when investigating access or role queries rather than relying solely on a person's current profile.
• Keep individual administrator accounts separate so the Changed By information remains useful.
• Review both Store History and the existing Status History when investigating a wider profile-access issue.
• Avoid making unnecessary role changes simply to test access, as legitimate changes will become part of the profile's audit trail.