Permissions & security

On the Rules screen you decide per employee what they may do and which records they may do it to. Whatever is not explicitly granted is not accessible.

What you use this for

• Showing a technieker only their own jobs.
• Giving a team lead or regional manager the scope of their team or region.
• Hiding amounts from anyone who doesn’t need them.
• Checking who granted a particular access, and when.
• Reviewing rights when someone changes function.

Who can use it

Role	What they do
Company administrator	Creates roles and assigns them
All users	See the effect at their next login

Prerequisites: you must be company administrator. Permissions are loaded at login — have the employee log in again after a change. System and maintenance permissions are out of reach of this screen.

Two questions per employee

A permission always consists of two parts. That distinction is the core of the whole system:

Question	Answer
What may they do?	Level: read, create, edit, delete, approve, export
On what?	Scope: own, team, branch, region, whole company

The scope

Own ─▶ Team ─▶ Branch / territory ─▶ Region ─▶ Whole company
 smallest                                        largest

Scope	Who typically gets it
Own	A technieker: only their own jobs
Team	A team lead
Branch / territory	A branch manager
Region	A regional manager
Whole company	Dispatcher, planner, owner

Start tight

Grant the smallest scope the work allows. Someone who is missing something reports it within a day. Someone who sees too much never reports it.

Ready-made roles

A level and a scope per module, with the preview.

You don’t start from scratch. Around fifty role templates typical of service businesses are ready — from technieker and team lead to dispatcher, warehouse keeper, accountant and owner.

1. Open Rules and go to Employees.

2. Pick the employee and assign them a role.

3. To deviate, create your own role based on a template.

4. Use the preview to check what the role actually grants before you assign it.

5. Have the employee log in again so their new permissions take effect.

Financial rights

Amounts are a separate right. Without financial rights a user sees the full operational story — customers, sites, assets, interventions, parts, hours — but no amounts at all.

This applies everywhere in the same way:

• the Invoices and Financial tabs in the Customer File 360°
• the Finance dashboard
• the maintenance costs in Asset Intelligence

One lock, everywhere

Financial visibility hangs on the same right throughout the system. You therefore don’t have to repeat it screen by screen — and no screen bypasses the lock.

Techniekers in the app

Techniekers work in the Technician App with a restricted account. They see only their own jobs, and that partitioning happens on the server — not in the app. A modified phone or browser changes nothing.

The audit trail

Who made which change, and from which state to which.

Changes to roles and assignments are kept in an audit trail from which nothing can be erased: who made the change, when, and what the old and new state were.

That is what you need when someone asks afterwards “who granted that access?”

Company administrator

One or more users are company administrator. They may manage roles.

The last administrator is protected

The last active administrator cannot be deactivated and cannot lose their administrator role. So you can never lock yourself out of your own environment.

Roles can never hand out system or maintenance permissions. Those are structurally out of reach of the roles screen — even an administrator cannot give them away by accident.

Multiple companies

If you work with multiple companies, each user only sees data for the companies they have access to. That partitioning carries through every screen: dashboards, maps, files and reports.

Each customer also works in their own separate environment. Data from different customers cannot reach one another.

Your data

Security, backups and platform maintenance are managed by Digitalnatie. If you have specific requirements — a retention period, an export of your data, or documentation for an audit — contact your administrator; that is agreed per environment.

Best practices

• Work with roles, not per-person exceptions. Five roles you understand beat twenty-five records nobody can explain any more.
• Review permissions when someone changes function — not only when someone leaves.
• Grant financial rights to as few people as possible.
• Use the preview before assigning a role, rather than discovering afterwards what it opened.
• Walk the audit trail once a year. Five minutes, and you know whether your permission policy still matches reality.

Troubleshooting

An employee can’t see something. Now what? Check the scope first, not the level. In practice it is almost always a too-narrow scope, not a missing permission.

Changes aren’t taking effect immediately. Permissions are loaded at login. Have the employee log in again.

Can a technieker see a colleague’s jobs? Only if you give them team scope or wider. With own, no.

Can someone reach data through the app that they may not see? No. The partitioning is on the server, not in the app.

Can I create a role that may do everything? You can grant the full operational scope. System and maintenance permissions stay out of reach — by design.

Next step

• Roles & permissions — the three basic roles
• Customer File 360° — financial partitioning in practice
• Finance dashboard — behind financial rights
• Techniekers — employees and their access
• Integrations — who may connect external services
• Technician App — how techniekers log in