Meeting tags and context fields can only be edited by:
- The original meeting creator, or
- Another user who has been granted explicit delegation permissions by that creator.
This applies even if the editor has full admin rights.
Why can’t admins override this?
Although it may feel like something admins should be able to do, meeting metadata in Ezekia is treated as user-owned activity data, not generic record data. Editing another user’s meeting metadata is effectively acting as that user, which is why delegation is required rather than admin permissions alone.
What counts as “meeting metadata”?
Meeting metadata includes:
- Meeting tags
- Context links (assignments, opportunities, lists, people, companies)
- Meeting notes and classifications
These are all tied to the user who created the meeting.
Why is meeting data treated this way?
There are three main reasons:
1. Data ownership and audit integrity
Meetings form part of a user’s activity history. Allowing other users, even admins, to silently change metadata would break the audit trail and make it unclear who recorded or classified the interaction.
2. Outlook and calendar sync safety
Meetings often sync back to Outlook. Editing metadata created by another user without delegation risks conflicts or overwrites when the original owner’s calendar re-syncs.
3. Compliance and accountability
In regulated environments, it matters who tagged a meeting, linked it to a project, or added context. Ezekia preserves accountability by preventing cross-user edits unless delegation is in place.
Does this affect reporting?
It can, if meeting tags are applied inconsistently. That’s why Ezekia recommends:
- Clear internal tagging conventions
- Training users on correct meeting classification
- Using the delegation feature where admins need to review or correct activity (with permission)
What are the supported ways to correct meeting tags or context?
If an admin needs to correct or standardise meeting metadata created by someone else, the supported options are:
- Enable delegation from the original user to the admin (temporary delegation works too) but only with explicit delegation permissions from the user
- Ask the original user to update the meeting themselves
- Recreate the meeting under the correct owner (where appropriate)
Is this behaviour likely to change?
This behaviour is intentional and tied to data integrity, sync safety, and compliance. While feedback is always reviewed, unrestricted admin overrides for user-owned meeting activity are not currently planned.