A digital property record brings together all information, documents, choices and actions belonging to one home. Appropriate access rights ensure that residents, project staff and external participants see and do only what their role requires. Design these elements together: first decide which information belongs to which record, then define who can access it.
A general folder with a password is not enough. Once a project includes several homes, users and teams, it needs clear roles and a traceable administration process.
What belongs in a property record?
The record is the personal layer within a project. General project updates may be published elsewhere; property-specific information comes together here. Examples include:
- plot number, address, property type and relevant characteristics;
- final choices and their confirmations;
- property-specific drawings and documents;
- open actions, deadlines and reviews;
- messages with context about this home;
- handover and aftercare information.
Do not automatically put every internal detail in the customer record. Decide for each information category whether it is intended for the resident, only for the project team or for a particular specialist. This prevents internal notes from becoming mixed with published customer information.
Authentication and authorisation are different
Authentication checks someone's identity when they log in. Authorisation then determines what that user may see and do. The NCSC makes the same distinction in its explanation of identity and access management and advises organisations to assign access rights to accounts under an established policy.
For a property record, this means a valid login does not automatically grant access to all project information. After login, the system must connect the user to the correct project, record and role.
Design roles around responsibilities
Do not start with individual names. First describe the responsibilities that recur in almost every project. A simple model might include:
- Organisation administrator: manages core configuration and users at organisation level.
- Project administrator: sets up projects and records and oversees delivery.
- Project team member: publishes or handles information within assigned projects.
- Resident or buyer: sees their own environment, completes actions and asks questions.
- External specialist: receives access only to the defined area requiring their involvement.
The exact names matter less than the differences in permissions. Define for each role whether someone can read, add, edit, publish, approve and invite users. Include the role model in the functional specification when commissioning a customer portal.
Link users explicitly to records
A resident may belong to one home, but sometimes two buyers need access. An employee may work on several projects. Make these relationships explicit and check them before sending an invitation.
Do not use a broad role as a convenient workaround when an employee temporarily needs only one record. Extra access is easily forgotten. A narrowly defined link is easier to understand, check and later revoke.
Manage the full access lifecycle
Access management does not end with the invitation. Describe four stages:
- Request: who may request a new user or an additional role?
- Approve: who checks the project, file and permissions?
- Change: what happens after a change of role, a property transfer or a change in collaboration?
- Revoke: when does access end, and who checks that this has happened?
Schedule periodic reviews of users and roles. Look beyond active residents to former employees, temporary partners and accounts with broad management permissions.
Make publication a deliberate action
Uploading a file and publishing it for a resident are two different steps. That distinction gives the team room to check the content, version and audience. Before publication, show which project or files the document will be visible in.
For sensitive or personal information, use an additional check appropriate to the risk. For example, have a second person review the selected files. The appropriate measure depends on your data, process and risk assessment; a portal does not take over that responsibility.
Support privacy rights in the process
A customer portal often contains personal data. The Dutch Data Protection Authority emphasises that organisations need to configure their systems and processes so they can put privacy rights into practice. Record where personal data is held, who handles a request and how data is corrected, provided or deleted when applicable.
Do not retain more data ‘just in case’ without a purpose. Establish retention periods and responsibilities with your privacy and legal advisers, and make sure operational staff know which route to follow.
Test the customer view before sending an invitation
The management view may look correct while the customer-side association is wrong. Include a standard check in onboarding:
- open the environment using the intended customer role;
- check the project name, property and personal details;
- review all visible updates, choices and documents;
- check that information from other files cannot be accessed;
- carry out one action and check that the status is correct for both employee and customer;
- check the invitation, recovery route and contact information.
Repeat this test when roles, project structure or publication processes change substantially.
Record access changes so they can be checked
Make sure administrators can reconstruct when a user was linked to a project or file, which role changed and who made the change. Use that information for management and error investigation, not as a substitute for a sound approval process. Agree who may view these records and how long they are needed. Also test whether revoking an association immediately has the expected effect in both the customer and management views.
A file is also a working agreement
Technology can enforce access, but it cannot decide which colleague is responsible for correct classification and publication. Record ownership. Who creates a property file? Who checks the data? Who closes or transfers the file after handover?
A digital handover file becomes more reliable when these agreements apply from the start. The detailed Baken Bouw use case shows how project and property levels can come together in one portal model, without attributing measured live results to it.
Yindle Portal supports a central setup around projects, files and users. Discuss your file structure and roles model before inviting the first users.