CRM Access and Offboarding: Who Can See What, and Removing a Former Employee the Same Day

Access is the part of a CRM nobody thinks about on the day they buy it, and everybody thinks about on the day someone quits, is fired, or finishes a storm season and does not come back. If that person shared the office login, there is nothing to remove — the password is in their phone, their old text threads, and probably a notebook, and the only fix is changing it for everyone. If they had their own login but nobody owns removing it, it can sit live for months, attached to a person who now works for a competitor, while their old jobs, estimates, and homeowner details sit behind it. And if access was rationed because seats cost money, the record was never trustworthy in the first place: shared logins mean the job history cannot say who actually did what. None of this needs a security incident to matter. It is a housekeeping discipline, and it is cheap — if it is set up before anyone leaves.

One login per person is the whole foundation

Every other rule in this post depends on this one: each person who touches the record gets their own login, under their own name, and nobody shares. A shared login breaks three things at once. It breaks accountability — a stage move, an edited estimate, or a deleted note cannot be traced to a person, only to “the office account.” It breaks offboarding — you cannot remove one person from a login four people use without disrupting the other three. And it breaks trust in the record itself, which is how crews drift back to private trackers: our guide to shadow spreadsheets after buying a CRM traces a lot of that drift to people not having, or not trusting, access of their own. Per-seat pricing pushes companies toward sharing, because every login is a line on the bill. That is a pricing problem before it is a discipline problem — count it when you compare systems, the way our roofing CRM demo checklist tells you to count every seat at today’s crew and at storm-season size.

Who can see what: assign the smallest role that does the job

Roles exist so access can follow responsibility instead of seniority or habit. GableFlow’s team roles are owner, admin, manager, and user, and they control who can see and change what — the pattern on our features page is that sales reps see their pipeline while the office sees everything. Assigned well, that looks like this:

Two cautions keep that table honest. First, it is an assignment pattern, not a promise about any one system’s exact permission switches — test the actual roles in the actual settings before you rely on them, ideally during the trial, as our 7-day trial test recommends: confirm each role sees what its job requires, and check how removing a person works while you still have nothing to lose. Second, do not hand out owner or admin access as a convenience. Every extra broad login is one more account that can invite, export, or delete — and one more removal you have to remember on a bad day. Keep broad access to the smallest named group, and write down who is in it.

Access follows the assignment, not the person

Once roles are set, the day-to-day rule is simple: people see a job because they are working it, not because they once did or might someday. A rep is assigned the leads they own; production sees the Approved jobs they have to build; the office sees across the board because billing and follow-up live there. When a job changes hands — a rep is out, a storm hands you more leads than one person can call — reassign it on the record instead of widening everyone’s access “just in case.” The @-mention is the lighter tool for the one-off case: loop a teammate in on a single job with a notification, rather than opening the whole pipeline to them. Temporary help gets the same treatment scaled down: seasonal and storm help get their own logins, at the smallest role that fits the work they were brought in for, for as long as they are actually working — which means their access has a planned end date when it is created, not an unplanned discovery months later.

The same-day offboarding sequence

When someone leaves — quit, fired, laid off, or a temp’s last day — removing access is a same-day task, owned by a named person, not a “when we get to it” item. The order matters less than that every step happens:

• Remove or deactivate their CRM login that day, before the end of their last working day — not at the end of the week, and not after a notice period spent with live access to current homeowner and claim details
• Reassign their open work on the record in the same sitting: every Lead and Prospect they owned, every undecided estimate waiting on follow-up, and every Approved job where they were the contact — each to a named person, so nothing stalls silently
• Work through what only they knew: jobs where they were the sole contact, promises made to homeowners, and any @-mentions or tasks still pointing at them, and write what matters onto the job records themselves
• Change any genuinely shared credentials they knew outside the CRM — the reason the one-login rule exists is to keep this list near zero
• Confirm the removal out loud and note it: who removed the access, on what date, and that the reassignments were checked — a one-line record beats a memory
• Check the rest of their footprint at the same time: if they used their own phone for field work — most crews do — the company’s photos and job details should already be on the job records, not only in their camera roll; if they are not, that gap is a process failure to fix for everyone, as our field photo checklist sets out

None of that touches the person’s history, and it should not. The estimates they sent, the photos they captioned, the notes and follow-ups they logged — that is the company’s job record, and it stays. Offboarding removes a person’s ability to see and change the record going forward; it does not rewrite who did the work while they were there. That distinction is the same one that governs the company’s own exit: our guide to getting your data out of a roofing CRM makes the point from the other side — the record belongs to the business, and access to it should be deliberate in both directions.

The joining side: set access up like you will have to remove it

Good offboarding is mostly decided on the day someone starts. Give a new hire their own login on day one — not the departing rep’s, and not a spare shared one — at the role their actual job needs, and have them sign in on their own phone while someone can help, so a dead login never becomes the excuse for working off-record. Show them which jobs are theirs, how an @-mention reaches them, and what a complete record looks like for their stage of the pipeline. And put a review date on the calendar at the moment you create any temporary access: storm-season help, a sub who needs to see one job’s photos, a bookkeeper who needs invoice access for a project. Access created with an end in mind rarely becomes access nobody remembers.

A short, regular access review

Even with clean joining and leaving, lists drift: a manager who moved to the office still holds both roles’ habits, a temp from last storm is still on the roster, someone’s role grew informally because it was faster than asking. So once a month — the Monday-numbers rhythm most owners already keep works — read the user list against the current roster and ask three questions. Is every name on this list a person who works here now? Does each person’s role still match the job they actually do today? And is the group with owner or admin access still the smallest group it can be? Any name that fails the first question is removed that day, not noted for later. The review takes minutes when the list is short and current, which is exactly why it has to happen while it is still short.

In GableFlow, that discipline runs on the structure already described: team roles (owner, admin, manager, and user) controlling who can see and change what, reps seeing their pipeline and the office seeing everything, @-mentions to loop a named teammate in on a job, and every job on the six-stage pipeline (Lead → Prospect → Approved → Completed → Invoiced → Closed) with its branded estimates, photo reports, documents, invoices, and payments on one shared record — so reassigning a departing rep’s work means reassigning visible jobs, not excavating their phone. Because seats are unlimited on the flat $40/month pricing, nobody has to share or ration a login to keep the bill down: every person gets access of their own, and every removal is clean. See how GableFlow’s team roles and job features fit together, and use the 7-day free trial to test the removal path with a real name before you ever need it for a real departure.