Roles and permissions in a multi-branch CRM: who should see what

When an agency opens its second branch, it usually keeps using the same CRM account that worked for the first one, with the whole team sharing a single login. That's fine while it's four people who know each other by sight and sit in the same room. Once headcount grows — an agent in Seville, another in Málaga, a manager at each site — that early convenience becomes the reason anyone can edit a listing that isn't theirs, mark a flat as reserved by mistake, or simply browse the other branch's portfolio without anyone noticing.

Managing permissions in a multi-branch real estate CRM means assigning every user a role and a branch from a central panel: the role decides what they can do inside the system, and the branch — or branch group — they belong to decides which part of the portfolio and contacts they see, so an agent never needs to open data from a site that isn't theirs.

What changes once you go from one branch to several

With a single branch, sharing a login barely hurts: if something gets deleted by mistake, it's usually obvious who was at the keyboard. With two or three sites, that stops being a minor annoyance. A flat that shows up reserved with nobody remembering marking it that way, two agents from different branches calling the same contact the same day without knowing it, a former employee still logging in months after leaving because nobody changed the shared password — these are small frictions on their own, but they pile up fast once there's more than one site and more than one manager.

Users, roles and branches from the same panel

RealEstateCRM's multi-branch administration module centralises users, roles, branches and branch groups from a single panel, with no cap on the accounts you can create. In practice, that keeps two questions apart that shouldn't get mixed up: what a person can do inside the CRM — their role — and which portfolio is actually theirs to see — the branch or branch group they're assigned to. An agent works within their own; whoever coordinates several sites can get visibility across all of them without waiting for each branch to forward its own spreadsheet.

2FA and an access log, not just a list of names

Splitting users across branches only solves half the problem; the other half is knowing who logged in, when, and how securely. The CRM includes two-factor authentication and a per-account access log, so a leaked password alone isn't enough to get in, and if something changes oddly on a record there's a history to check instead of relying on memory to work out who was on shift that afternoon. For an agency handling buyer and owner data — not just listings — that traceability matters as much as the role split itself.

A case: letting an agent go mid-season

An agency with offices in Málaga and Seville had to let go of an agent at the Málaga branch in mid-April, right after publishing its spring portfolio, with several viewings already booked under their name. With the shared login they used until then, cutting off access would have meant changing the password for the whole branch and handing out the new one by hand, risking locking someone out on a Monday morning with viewings on the calendar.

With individual users and roles per branch, the departure was handled by disabling just that one account from the admin panel: the rest of the Málaga team kept logging in with their own credentials, their viewings and records stayed untouched, and the Seville branch never noticed the change, because it never had access to data that wasn't its own.

This split between roles and branches sits alongside the rest of the CRM's modules — Properties, Contacts, Reports — which is what each user ends up seeing or not depending on the permission they've been given. If your agency already runs several branches and you want to see how to compare their activity without mixing one site's numbers with another's, the article on the KPIs worth checking every week is a good next read.