crm data-protection permissions roadmap
Some decisions are made exactly once. How you sign in, who owns which data, who is allowed to see what. None of that can be changed later without disturbing everyone who already works with the software. So we are settling this foundation of our property software now, before the launch on 1 January 2027 and before the first paying customer.
This post describes a plan. Not all of it is built yet, and we say which parts are intended and which already stand.
Two prompts from practice
The first came from estate agents themselves. They do not want to assign tasks and projects to a user account but to a person, to their colleague with a name. That sounds like a detail and is a question of principle, because it decides what everything in the system points at.
The second came from data protection. Anyone running a platform on which several firms work has to be able to explain who can see which data. An operator who may technically see everything is hard to defend as a processor. So we turned the question around and asked how little operations actually needs to see.
Running the platform does not mean reading along
A clear separation is planned. Operations looks after the technology, creates firms, allocates storage and web addresses, sets up backups and configures servers. It does not look into the business data of the firms, so not into contacts, properties and messages.
The firms administer their own users. This is not distrust towards our own operations, it is the simplest answer to the question of who has access: as few people as possible, and only where the task requires it.
A test firm and a real firm are two different things
Every firm on the platform is either a test environment or a real customer, and that makes a difference.
In a test environment operations may work freely, for instance set passwords in order to check procedures with many test users. With a real customer that ends. There, nobody from operations sets a password or changes a user account. An invitation and a forgotten password run exclusively by e-mail to the person concerned.
The change from test to real is a one-way street. All previous passwords expire in the process, and the first administrator of the firm receives her invitation. There is no way back, because from that moment on there is real data about real people.
The person, not the user name
Take Anna Berger, an estate agent and the owner of a small office. In our planning she is first a person with a name, a phone number and an e-mail address, and only after that someone who can sign in.
That has consequences in daily work. Tasks, appointments, messages and responsibilities always go to the person, not to an account. Lists show her name everywhere, not an abbreviation. User names will only be visible to the administrators of the firm, because nobody else needs them.
Two hats for one person
We separate administering and working into two accounts. An administrator account manages users, roles, teams and settings but does not work in contacts and properties. A staff account does the professional work and administers nothing.
Anna Berger can have both, like two hats. Under each hat she sees her own messages and matters, and under each hat she may do exactly what that hat is meant for. So that a firm cannot lock itself out, the last administrator account is protected and can neither be deleted nor blocked.
Signing in with the firm
Every firm gets a short, fixed identifier. You sign in with that identifier, the user name and the password. That way two firms can each have a sign-in called “info” or “office” without anything colliding. The program remembers the firm identifier, you only type it the first time.
Roles instead of special cases
Tenants, owners, buyers, tradespeople and staff are not different kinds of contact in our planning. They are roles of the same person.
Mrs Berger can be the owner of one flat and the tenant of another at the same time. Every role brings what belongs to it, a tenancy for instance the unit, the period and the rent. The person stays the same, and nobody has to maintain her twice.
This is also the basis for the planned property and community management. It builds on the same contact base instead of creating a second one next to it, and every field gets its own view of the same person.
The permission model is the actual work
Three things belong together for us.
Contact management is the backbone of every installation, so people, companies, addresses, e-mail, calendar, tasks and files. Specialist modules build on it. A property manager does not have to see the sales part of an estate agent, that can be hidden.
Every record can be linked to every other one, as owner of, employee of or simply belongs to. Such a link reveals nothing you are not allowed to see. Where the permission is missing, there is a note instead of a name.
And there are no silent workarounds. When something does not work because a module is missing, a permission is missing or a record was deleted, the interface says so with the reason, already in the list. It does not open something else instead. You should be able to rely on what you see.
A log that is not a shadow copy
Important actions are logged, so who did what and when, with which account and by which route, whether in the program, through the website or through the AI assistant. Entries cannot be changed afterwards.
What the log deliberately does not contain is content. No addresses, no notes, no field values. Otherwise a second collection of the same data would grow next to the data itself, and that is exactly what we do not want. Each firm sees its own log, operations only its own platform actions. That turns the accountability required by the GDPR into something you can show.
A demo on request instead of a showroom
There will be no public demo in which everyone clicks around together. Anyone who wants to try the software applies for their own demo installation through a form. It is set up from a prepared template, adapted and handed over by invitation.
The reason is the same as above. As soon as a real person works with their own data, the same rules of protection apply as for a customer. Later a script or an AI assistant is to take over this setup, following the same rules that apply to a human being.
First the data, then the interface
Finally the principle we follow while implementing this. The data and the rules on the server come first, the interface afterwards. We do not build operating concepts on spec.
The first stage therefore brings only as much interface as is needed to maintain and check things, and it follows the same patterns as everywhere else in the program. Conveniences such as dedicated views for tenants and owners, or a quick switch between the two hats, will come when a specialist module really needs them.
We consider this the more honest way. An interface can be added at any time. A foundation cannot.
