What it does
Admin access is managed as delegated grants. A named person gets an admin role at a scope — the organization, one institution, or a program — with a start date, an optional end date, and a reason.
Who it's for
Org admins govern access across the account, institution and program admins manage admins within their own scope, and any user can see their own grants. Managing other people's grants needs governance authority over that scope.
How it works
Choosing a grant kind. Pick Administrator (full management access at a chosen scope) or Access profile (specific capabilities only) at the Grant access menu — never both in the same grant. The panel that opens shows only the steps for that choice.
Picking scope and people. Broad admin surfaces let you search organizations, institutions, and programs before choosing people. Scope-specific surfaces — a program hub, or an institution's own Add admin button — skip that step, since the scope is already known. Institution and program targets can be selected in batches, and a final review step summarizes who gets access, where, what type, when it starts and expires, and why, before you submit it.
Access profile grants. Instead of a named admin role, a grant can give one or more access profiles — predefined permission sets that shape what the person can do at a scope, without making them an admin. The built-in Read-Only Observer profile gives view-only access with no create, edit, or manage actions, the right choice for analysts, auditors, and committee members.
Governance gaps. A separate view lists scopes missing an expected admin, ranked by severity, so you can spot an institution or program with no responsible admin before it becomes a problem.
Audit trail. Every grant, update, and revocation writes an audit event, with the actor, target person, scope, permission details, before/after values, reason, and timestamp. The audit log is filterable by scope.
Authority hierarchy. Authority flows downward by default: an admin manages tiers below their own, so an org admin can grant institution and program admins, and an institution admin can grant program admins. Same-tier ("peer") creation is set platform-wide by Medtrics, not per scope. Two rules are fixed — only Medtrics platform admins can create org admins, and org admins can always create institution and program admins.
Medtrics can also set platform-wide limits on what org admins see, such as hiding people whose home program sits inside the org. Removing an admin deactivates the grant as a reversible archive; the history and its audit events stay.
Before you start
You need governance authority over the target scope. Being able to see grants there doesn't mean you can change them.
Know who you're granting access to, at what scope, and why — the last step requires a reason.
Do this
Open the
/organization/administration/permissionspage → Access & governance loads on the Grants tab.Select the Grant access button, then choose Administrator or Access profile from the menu → the grant sheet opens, locked to that choice.
In the Where section of the sheet (skipped if launched from a specific scope), select one or more scopes → the Next button advances to the next section.
In the Who section, search or browse and select the person or people → select Next again to advance.
For an access profile grant, in the What section choose one or more profiles → select Next to advance.
In the When section, optionally set Starts and Expires, then fill in the required Reason field → select Review to reach the review section.
Review the summary in the Review section, then select the submit button → the sheet closes and the new grant appears in the Grants table.
You're done when
✓ The new grant shows in the Grants table with the right person, scope, and grant type.
✓ The person can now access what the grant covers, at the scope you chose.
✓ The audit log shows a new entry for this grant, with your reason attached.
Boundaries and limits
Writing a grant needs authority over the target scope, checked on the server: the scope must be within yours, rank matters, and platform-wide policy applies. Seeing grants in a scope doesn't mean you can change them.
Same-tier ("peer") creation is off unless Medtrics turns it on platform-wide. Downward management is always available, and only Medtrics platform admins can create org admins.
Audit events can't be edited or deleted by anyone. The platform rejects those changes.
Grant records can't be hard-deleted. Revocation is a soft archive that keeps the history.
Changing an admin's tier isn't an edit. Revoke the old grant and issue a new one, so the audit trail stays clear.
Users always see their own grants and any audit events that involve them, even without governance authority.
Common questions
Q: How do I give someone read-only access across programs? A: Grant them the Read-Only Observer access profile at the right scope. They can view data everywhere in that scope but can't create, edit, or manage anything.
Q: Can I make someone an admin temporarily? A: Yes. Set an expiration date on the grant. Check expiring grants from Access & governance or the audit log when renewals are due.
Q: Why can't one program admin add another program admin? A: Same-tier ("peer") creation is off by default and is now controlled platform-wide by Medtrics. An admin above that scope — an institution or org admin — can make the grant instead, or ask Medtrics to turn on peer creation.
Q: Why can't an org admin see every person or site in a program? A: Medtrics can set platform-wide limits on what org admins see — for example hiding people whose home program is inside the org, or program-specific sites. Institution and program admins are unaffected.
Q: Who can see the audit log? A: Users with governance authority over the scope, plus the people directly involved. The actor and the target of an event can always see it.
Q: What is a coverage gap? A: A scope missing an expected admin — for example a program with no active program admin. Gaps are listed with severity, so the most exposed scopes show first.
Related articles