Municipal Portal User Permissions

Modified on Sun, 19 Jul at 2:12 PM

Understanding User Permissions

Civify uses a role-based permission system to control what each team member can see and do within the platform. When you invite someone to your organization, you assign them a user type — and that user type determines their default access across every area of Civify, from projects and road restrictions to resident communication and org settings. A user's type can be changed at any point.


Access in Civify is made up of three parts:

  1. User type — Org Admin, Admin, Staff, or External User
  2. Capabilities — what actions someone can take (view vs. edit, create projects, manage users, and so on)
  3. Content visibility — which records they can see (only their own, their assigned work, their department, or the whole organization)

Org Admins have full access to everything and don't use the detailed permissions panel. Everyone else is controlled by their capabilities and visibility settings.


User Types

There are four user types:

User typeWho it's forHow access works
Org AdminThe primary account holder or platform owner (one per organization)Full platform access. Permission settings don't apply to them.
AdminDepartment heads or anyone who needs broad management accessFull day-to-day access across the platform. Configurable capabilities and visibility. 
StaffStaff working in Civify regularlyStandard, configurable access. Usually needs to be assigned to a project or post to work on it, depending on visibility settings.
External UserContractors, consultants, and inspectors who need temporary or limited accessSame capability model as Staff, but with no department, a defined access window, and visibility capped at Assigned or Own only.

Note: Org Admins can restrict which email domains are allowed to access the organization, from organization settings.

Residents are managed separately under Residents and are not configured through the staff permissions panel.


Setting Permissions

  1. Open Users in the sidebar.
  2. Choose Add User, or select an existing user to edit.
  3. Set the Account Type.
  4. Under Permissions, click Change.
  5. Apply a quick preset, then adjust individual settings as needed.
  6. Save the user.

On the Permissions screen you'll find:

  • Quick presets (Admin, Staff, Contractor, Consultant, Inspector)
  • Content visibility settings for each content type
  • Capability groups, each set to None, View, or Edit
  • Department assignment (for Admin and Staff users)
  • External access details for External Users — company, type, and start/end dates

Capabilities: What Someone Can Do

Capabilities cover actions across areas like:

  • Projects (view, add, delete, export)
  • Collaboration tools — checklists, punch lists, design reviews, daily reports
  • Public communication — gallery, resources, status updates, feedback, notifications
  • Posts and portal ordering
  • Users, data export/delete, and help links
  • Templates
  • Organization settings (subscription, integrations, departments, phases, types)
  • Routings and road restrictions (if your organization has those modules)
  • Resident portal banners and Residents CRM actions
  • Sidebar items like Directory, Team view, My tasks, and Calendar
  • Editing their own profile or department

For each capability, you choose a level:

LevelMeaning
NoneNo access
ViewCan see or open, but not change
EditCan create, update, or manage

Some capabilities are view-only or allow-only by design, so not every level is available for every item.

Note: Menu items for licensed add-ons like Routings or Road Restrictions only appear if your organization has that module.

Content Visibility: What Someone Can See

In addition to capabilities, each user has a content visibility scope that controls how broadly they can see projects, posts, feedback, communication history, and residents. Visibility is separate from capabilities — someone might be allowed to edit projects in general, but only be able to see the projects they're assigned to.


From narrowest to broadest, the scopes are:

ScopeTypical meaning
Own onlyOnly content they created (for example, only the notifications they personally sent)
AssignedAnything on projects they're assigned to (for example, notifications sent by anyone on a project they're on)
DepartmentEverything within their department(s) — users can be assigned to multiple departments
Org-wideAll content across the organization


Admins default to Department scope. Most other user types default to Assigned or Own only. These scopes can be adjusted per user from the Users settings page.


A simple way to think about it: capabilities decide what they can do, visibility decides which records they can do it on.


Permission Ceilings

A permission ceiling means you can't grant another user more access than you have yourself. This applies whenever you create a user, edit their permissions, or apply a preset that would otherwise exceed your own access. If a setting would go above your ceiling, Civify blocks it and shows Permissions ceiling exceeded.

Capability ceiling. Levels increase as None → View → Edit. You can only grant a level equal to or lower than your own for that same capability. For example, if you only have View on Projects, you can't give someone else Edit on Projects.

Visibility ceiling. Scopes increase as Own only → Assigned → Department → Org-wide. You can only grant a scope equal to or narrower than your own. For example, if your own Projects visibility is Assigned, you can't grant someone Department or Org-wide Projects visibility.

Who isn't limited by a ceiling? Org Admins. They sit at the top of the access model and can grant any permission.

A few things worth keeping in mind:

  • The ceiling is based on whoever is making the change right now — not on who originally created the user being edited.
  • Being linked to the same organization account doesn't automatically copy anyone's permissions to anyone else.
  • External Users can never receive Department or Org-wide visibility, even if an Org Admin is the one editing them. Their maximum is Assigned.

Special Rules by User Type

Org Admin

  • Full access; the permissions panel doesn't apply to them
  • Can manage every user in the organization
  • Can assign departments to Admins
  • Can restrict organization access by email domain

Admin

  • Configurable permissions
  • With Users edit access, can manage users within shared departments
  • Typically cannot manage Org Admins or organization-wide administration — that's reserved for Org Admins

Staff

  • Configurable permissions
  • Usually works within assigned projects and posts unless visibility is broadened
  • Department membership and visibility are related but not identical — someone can belong to a department and still have narrower or broader visibility depending on settings

External User

  • Requires access start and end dates
  • No department assignment
  • Visibility limited to Own only or Assigned
  • Categorized as Contractor, Consultant, or Inspector
  • Access can end automatically once the window expires

Residents

  • Use the resident portal, not the staff permissions panel
  • Staff access to resident records is controlled separately through Residents capabilities and visibility

Departments and User Management

  • Department membership controls where someone "belongs" in the organization.
  • Visibility controls which records they can actually see.
  • Users generally can't change their own department assignment.
  • Only Org Admins can assign departments to Admins.
  • Admins can typically place Staff only into departments they themselves belong to.

Examples in Practice

Safe handoff. A Staff user with Assigned project visibility invites a contractor. Even if they select a broad preset, Civify clamps the grant to that Staff's own ceiling — the contractor can't end up with broader project visibility than the person who invited them.

Setting up a department Admin. An Org Admin creates an Admin for Public Works, assigns them to Public Works, and grants Users edit access. That Admin can now manage staff within Public Works, but still can't exceed the functions reserved for Org Admins.

Bringing on an external consultant. An Org Admin creates an External User as a Consultant, sets an end date, and keeps Projects visibility at Assigned. The consultant only sees the projects they're placed on, and their access ends automatically once the date passes.

In Short

Org Admins can grant any level of access. Everyone else can only grant capabilities and visibility equal to or narrower than their own — and External Users can never receive Department-wide or Org-wide visibility, no matter who's editing them.



User Permission Presets




Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article