Before applying a new role to a bookkeeper in UnitConnect, review their current roles, individual permission exceptions and property selections. Applying a role replaces the user’s existing roles and clears their individually granted or denied permissions. That makes a role change more than a job-title update: you need to know which exceptions should remain afterward.
This guide is for the administrator making that change, whether a bookkeeper is taking on another building, moving to review-only work or handing some tasks to a colleague. The goal is a specific access check—not granting the broadest role just to get past a missing control.
Start with the work the bookkeeper should do
Write down the intended tasks and properties before opening the user’s settings. A request such as “give Avery the office building” leaves two questions unanswered: which functions should Avery perform, and which other buildings should remain visible?
For example, someone may need to view vendor information and review reports for two properties without recording payments. Treat those as separate decisions. The role supplies a bundle of tasks; property access determines the buildings the person can see.
UnitConnect’s users and access feature supports this separation. Choose access around the actual assignment rather than assuming that everyone with the same job title needs the same scope.
The person performing the review needs permission to view users, and changing access requires permission to modify users. You cannot change your own role, permissions or property access from your user profile. Have another authorized administrator make changes to your account.
Capture the current exceptions before selecting Apply
Find the bookkeeper in the user list and open their details. Review Roles & permissions before changing anything. The Current area shows the roles the user has now.
The task list also explains where access comes from. A Role tag means the task is granted through a role. Granted identifies an individual grant. Denied identifies an individual restriction, including a task that would otherwise be granted by a role.
Use Search task or code to locate relevant tasks and Selected only to review those currently enabled. Record any individual grants or denials that are still required for the new assignment. Checking only the role’s name can miss those exceptions.
The current Manage users guide documents the important warning: choosing a role and selecting Apply replaces all of the user’s roles with the selected one and clears their individual permission grants and denials. Do not assume Apply merely adds another role or preserves an earlier restriction.
Decide whether this is one person’s change or a shared-role change
A single bookkeeper’s exception does not necessarily require editing the role used by the rest of the team. UnitConnect lets an administrator grant or deny individual tasks for one user without changing the shared role.
Editing the tasks on an existing role has a wider effect. Those task changes save as soon as you tick or clear a checkbox and affect every user assigned that role immediately. Before changing a shared role, review who uses it and whether the same change is appropriate for them.
System roles are read-only. You can inspect and assign them, but you cannot modify their task bundle. If the assignment needs a different reusable bundle, review the current Create and manage roles guide rather than treating a system role as editable.
Use a replacement role when the person’s overall responsibilities are changing. Use a carefully considered individual exception when the shared role is otherwise appropriate and the difference belongs to this person alone.
Apply the planned role, then restore the intended exceptions
Once the replacement role and required exceptions are clear, select the intended role under Roles & permissions and choose Apply. Review the task list again after that action.
If a required restriction or additional grant was cleared, set the intended individual task permissions for the new assignment. The tags help distinguish the new role’s permissions from the user-specific adjustments you make afterward.
These checkbox changes save immediately. There is no Save button on this tab, so do not toggle tasks just to experiment with a possible setup. Make the changes you have planned, and check the resulting permissions before treating the handoff as complete.
Check Properties separately—and consider future buildings
Open the user’s Properties tab. All properties grants access to every property, both now and in the future. That can be appropriate for a company-wide assignment, but it is not the same as access to the buildings currently on a bookkeeper’s desk.
For a limited assignment, clear All properties and select the individual properties the person should see. These changes also save immediately.
Review this tab as its own part of the handoff. A suitable task bundle is not a substitute for checking property scope, and a correct property selection is not a substitute for checking the tasks the person can perform.
An illustrative handoff: review two properties, not the whole company
Suppose Avery previously helped with several properties and is moving to review-only work for Cedar Retail and Elm Office. The intended assignment includes viewing vendor information and reviewing reports for those two properties, but not recording payments. North Warehouse is outside the new assignment. These names and responsibilities are an example, not a predefined UnitConnect role.
Before the change, the administrator finds that Avery’s current role grants payment-recording access but an individual Denied exception removes it. That exception matters: applying a replacement role clears individual denials. If the new role also grants that task, the old restriction must not be assumed to survive.
The administrator checks the proposed role’s tasks, applies the appropriate replacement and reviews the resulting list. Any required individual denial is then set deliberately. In Properties, the administrator checks whether All properties is selected and limits access to Cedar Retail and Elm Office for this assignment.
Finally, Avery checks the expected work in their own login. The administrator and bookkeeper confirm that the intended properties and functions are available and that work outside the agreed assignment is not. If something is wrong, they return to the specific task or property setting instead of automatically choosing a broader role.
Finish with an access check, not just a changed role name
A useful handoff note records the intended role, the individual exceptions that remain and the selected properties. It should also say whether access is limited to named buildings or includes future properties through All properties.
That short record gives the next administrator something concrete to compare when responsibilities change again. More importantly, it keeps the review focused on what the bookkeeper can actually do and see after the change—not simply whether a different role name appears.
Want to walk through a bookkeeper-access setup for your portfolio? Schedule a UnitConnect demo and discuss how roles, individual task permissions and property selections fit your team’s division of work.
