Admin roles for site-linked admins on Vome: how site scope and role permissions combine

How do admin roles work for site-linked admins?

Overview

Linking an administrator to a site already decides most of what they can reach. The admin role you give them then either holds that boundary, narrows it, or opens it back up. Those are two separate layers, and mixing them up is the usual reason an admin sees too much or too little.

This article explains what the site link does on its own, what each admin role option does to it, which modules can be scoped to a site, and how to build a role that keeps someone inside their site while still giving them the wider access their job needs.

Info
Plan required: the Sites module and custom admin roles are both available on the Enterprise and Ultimate plans.

1. What does linking an admin to a site do on its own?

It scopes them to that site. Once an administrator is linked to a site, the opportunities, forms, sequences, groups and profiles linked to that site are the ones they work with, and what belongs to other sites stays out of their way. You do not have to configure anything module by module to get that behavior.

An administrator linked to more than one site gets all of those sites together, so their scope grows as you link them to more sites. If you never give them a custom admin role, the site link is the whole story. For what a site is and what can be linked to one, see How do Sites work on Vome?

2. So what does the admin role change?

The admin role decides, module by module, whether their access stops at the site boundary, stops short of it, or reaches past it. The role is the layer that wins, which is why the same site-linked administrator can be set up three very different ways:

  • Held at their site. "Access only to opportunities linked to their sites", and the equivalent option in the other modules.
  • Narrowed inside their site. "No access" in a module takes that module away even though their site has plenty of items in it.
  • Widened past their site. "Access to all opportunities" gives them everything in the organization, site link or not.

3. What does each option do to the site scope?

Every module that lists items follows the same four-option pattern. Opportunities as the example, and the note under each option in the popup says the same thing:

  • Access to all opportunities. Organization-wide. This gives them access to all opportunities across the organization, even if they are linked to a specific site.
  • Access to some opportunities. Additive. The opportunities you tick are added to what their site already gives them, not swapped in for it.
  • Access only to opportunities linked to their sites. Exactly their site scope, nothing more.
  • No access to current opportunities. This overwrites the site-level access and leaves them with nothing in that module.

Forms and Sequences work the same way and carry their own wording of each note.

Caution
Caution: "No access" is not additive. An administrator linked to a site full of forms will still see none of them if their role says No access to forms. The role overwrites the site link in that direction.

4. Which modules can be scoped to a site?

Seven settings in the admin role offer a site-scoped option:

  • Opportunities. Access only to opportunities linked to their sites.
  • Forms. Access only to forms linked to their sites.
  • Form submissions. They can only access submissions from profiles linked to their sites.
  • Sequences. Access only to sequences linked to their sites.
  • Sequence dashboard. They can only access profiles linked to their sites.
  • Database. They can only access profiles linked to their sites.
  • Groups. Access only to groups linked to their sites.

Notes has a site-aware option as well. Under "View limited notes" you can tick "Notes by admins who share their site(s)", so an administrator reads the notes written by colleagues at their own site and not those written elsewhere.

5. Can an administrator see things outside their site?

Yes, if you allow it. The site link is a default, not a wall, and every module's role setting can override it in either direction. That is deliberate, because real jobs rarely sit tidily inside one boundary. Someone can run only their own site's programs and still need to search the whole organization for a returning person.

Alert
Important: a site-scoped option means "the items linked to their sites". An administrator who is not linked to any site has an empty set, so they will see nothing at all in every module set that way. Link the site first, then assign the role.

6. What does that look like in practice?

A local coordinator who needs the whole database. Opportunities, Forms and Sequences all set to "linked to their sites", so they only run their own site's work. The Database question set to "Yes, they can access all profiles in the database", because before creating a profile they need to check whether that person already signed up at another site. Local for everything operational, organization-wide for looking people up.

A fully contained site administrator. Every one of the seven settings on its site-scoped option, the Database included. They cannot reach a profile, a form or a shift that belongs to another site. This is what the recommended setup in section 7 produces.

A site administrator plus one shared program. Site scoping everywhere, except Opportunities is set to "Access to some opportunities" and the organization-wide annual gala is ticked. Because that option is additive, they keep their whole site and gain the gala on top.

A regional lead over several sites. Link them to every site in the region and keep the site-scoped options. Their scope is all of those sites together, so it widens as you link another site without anyone touching the role.

For the wider question of how to divide administrators up by location, see What are the best practices for creating admin roles for multi-location segmentation?

7. Is there a faster way to set this up?

Yes. When your organization has the Sites module active with at least one site created, the Create new admin role popup shows a banner at the top offering the recommended setup for a site-linked administrator. One click on Apply recommended settings puts every setting that offers a site-scoped option onto that option.

Treat it as the starting point rather than the finished role. Apply it first, then widen the one or two modules the job actually needs, which is exactly how the examples above are built.

8. An admin cannot see something they should. What do I check?

In this order:

  • Are they linked to the site the item belongs to?
  • Is the item itself linked to that site? A site-scoped role can only show what the site actually holds.
  • Is the module set to "No access" in their role? That overrides the site link.
  • Is a second condition also narrowing them, such as profile tags on the Database question?

For the database specifically, Why can't an admin see a profile in the database? walks through every condition that can hide a profile.

Summary

  • Linking an administrator to a site scopes them to that site by default, with no per-module setup needed.
  • The admin role then decides, module by module, whether that scope holds, shrinks, or grows.
  • "All" reaches past the site, "some" is additive to the site, "linked to their sites" matches it, and "No access" overwrites it and gives nothing.
  • Seven settings offer a site-scoped option, plus a site-aware option under limited notes.
  • An administrator with no site sees nothing in a module set to a site-scoped option.
  • Apply recommended settings in the Create new admin role popup sets all of the site-scoped options at once, and you can adjust any of them afterwards.

Still stuck? Submit a ticket, or email us at support@vomevolunteer.zohodesk.com.