Permission Keys
A permission key grants the right to perform one specific action — create a user, delete a subject, save a dashboard. Keys are collected into permission groups, and groups are assigned to people. Keys are never given to a person directly.
The full reference
Every key in eConnect, grouped by product area, with its friendly name, internal value, default groups and what it allows:
That page is the complete catalogue. This page exists so the manual has a route to it, and to point at the two things most people actually need.
New in version 11
Thirteen keys are new, covering Ace, the Security and Access report, attachments on subjects and plates, and bet-session recalculation. See Permission Keys in v11, which explains what each one governs and which should be granted narrowly.
The two rules worth knowing
Permissions are not scope. A key says what somebody may do; a logical group says what they may see. Somebody can hold every key and see nothing.
Rights only add. A person's rights are the union of every group they hold. There is no group that takes something away, so removing a capability means removing it from a group, not adding a restrictive one.
Enforced on the server
Keys are enforced server-side, not merely hidden in the interface. The desktop client, the browser, the API and Ace are all held to the same limits.
Seeing what somebody has
| Want | Use |
|---|---|
| What is assigned to one person | Their record — Assigning Groups |
| What they have actually done | Session History |
| A document of who holds what | The Security and Access Report |
The report resolves inheritance and reports the effective result, which is what an access review needs.
If a key is not in your list
You can only see and assign keys already granted to you. A key missing from your list means your own permissions do not include it — some, such as switching user group or managing resellers, are reserved for system administrators.