Mine, yours, ours: teams, permissions and groups

The last workshop report ended with the mail room learning to write back. Then the live test came in between — and with it a more important question: who is actually allowed to see all this? An estate agent office is rarely a one-person business. There is the boss, the team leaders, the agents — and there is data protection, discretion and simply the order of large portfolios. This week the estate agent software therefore got its permission model. And because such a thing quickly degenerates into a bureaucracy machine, one rule stood above everything: whoever does not need the model must not even notice that it exists.

Role and team: two questions, two answers

We looked at the big names of the CRM market and adopted the common denominator: visibility does not hang on subject categories but on two simple things. The role answers the question “what may I do?”, the team the question “whose data do I belong to?”. Both are separate, both are optional.

Teams are more than name lists: they form a tree. Whoever sits in the parent team automatically sees the data of all teams below — the team leader sees what her agents are working on without anybody having to assign anything twice. And on the role there are now the data scopes: a table in which, per kind of data — contacts, companies, leads — you set separately what the role may read, edit and delete. Four levels are available: all, team, own, none. “See all, but edit only your own” is thus as much a two-liner as “leads yes, delete never”.

Assigning itself is a right of its own — distributing work is the boss's business. Whoever has it marks ten leads in the list, chooses assign… in the context menu and gives them to an employee or a team. The rest of the team sees them at the same moment; the server enforces each of these rules even if a client wanted to bypass them.

Roles belong to the tenant

While testing it became obvious at once: none of this helps if only we as the operator can create roles. So the roles became multi-tenant capable: every office builds its own — the boss creates “team leader” and “agent” herself, with exactly the data scopes that suit her house. The delivered standard roles stay there for everyone, but untouchable. Role names only have to be unique within your own house; what the office next door calls its roles is nobody else's business.

Groups that bring their team along

Then this happened in the live test: an agent with team visibility created a new lead — and nobody except him could see it. Logically: the new record belonged to him personally, and without the assignment right he was not allowed to give it to the team. The record was stuck like a letter without a recipient.

The answer to that are the new groups. Every section — contacts, companies, leads — gets its own group tree: the filing structure of the office, nested the way the office thinks. And a team can be stored on a group. From then on: whatever is created or filed in the group automatically belongs to the team. The agent creates his lead in “flats, city centre” — and the whole team sees it immediately, without any assignment right, because filing is not assignment but order. An already given team is never silently overwritten.

Filing itself we also freed from clicking: rows are — as a multiple selection too — simply dragged from the list onto the group tree, like files into a folder. Whoever wants to resort a hundred old contacts drags them instead of opening a hundred dialogs.

Two finds from the workshop

The first find was delivered by the legacy data. Barely were the rules active when all lists were empty for restricted users — including the ones they should have seen. The reason sat deep: stock data from before the rebuild carries a database NULL in the new columns, and NULL in SQL is not the same as “not assigned”. The filter now treats both alike, and a regression test reproduces exactly that legacy state — so the trap never snaps shut again.

The second find is a design story. The groups started as one shared tree for all kinds of data — elegant on paper, wrong on screen: leads need different drawers than companies. So each kind of data got its own tree. And membership, at first freely multiple, was simplified to one group per record — a record lies in one place, like a sheet of paper. Both corrections came straight out of trying it, not three days after the first draft. That is exactly what we test on the living object for.

The balance

An estate agent office with three people installs, starts working and sees none of this. An office with thirty builds itself teams with team leaders, roles with data scopes and groups that put their records into the right team automatically — and each of these rules is enforced on the server, not merely hidden in the interface. Delivered complete as always: data model, server, desktop client, the tests green.

The mail room meanwhile waits patiently to learn to write back. Now that it is settled who owns the post, it can do so with a clear conscience.