---
title: "Organizational units (permissions)"
description: "The permissions that control access to and administration of organizational units, and which units' data an employee can see."
url: https://support.sapera.io/en/articles/551-organizational-units-permissions
collection: "Permissions"
updated: 2026-06-26
language: en
alternates: [da]
---

# Organizational units (permissions)

The permissions that control access to and administration of organizational units, and which units' data an employee can see.

This article covers the permissions that control **access to and administration of organizational units** — that is, your stores/departments — as well as which units' data an employee can see.

You assign these permissions in **Financial** under **Security → Groups** → select a group → **Permissions** (set Allow/Deny per permission). They apply **per organizational unit** — that is, only in the store/department where they are granted.

## The permissions

### Access

Determines whether an employee may **work in the organizational unit** — but the most important effect in practice is **data scoping**: the permission controls **which units' data the user can see at all** throughout Sapera.

-   Without **Access** to a unit, that unit is rejected at login and **silently filtered out** in lists, lookups and reports tied to organizational units. The user therefore does not get an error — the data is simply not there.
    
-   This is the permission that determines whether an employee in e.g. Store A can also see data from Store B. If you only grant **Access** to Store A, the employee only sees Store A's data, even if other permissions are in place.
    

In other words: **Access** is the main filter for which units' world a user sees — not just a login control.

### Show financial entries

Determines whether accounting and financial entries in the organizational unit are **visible** to the user.

-   If the permission is denied, lookups on financial entries return **nothing** for that unit — fields and lists of financial entries appear empty.
    
-   Note: the permission blocks the **data**, not the screen itself. The screen can still be opened, but it does not show entries from units where the user does not have this permission.
    

### Create

Controls whether **the create action for a new (sub-)organizational unit is shown in the user interface**.

> Important: This permission is a **user-interface control** — it hides the create action for employees who should not create units. Think of it as a tidying of the menu.

### Edit

Allows **editing an existing organizational unit's details** (name, setup, etc.).

-   If the permission is denied, the change is rejected with "access denied", and the edit form is disabled.
    

### Archive

Allows **archiving an organizational unit**.

-   If the permission is denied, the action is rejected with "access denied".
    
-   Note also a business rule: a unit **cannot** be archived if it has active (non-archived) sub-units — regardless of permissions. Archive or move the sub-units first.
    

## Good to know

-   **The permissions apply per organizational unit.** An employee may have the right to edit one store without having it in another.
    
-   **Access is the most important one to get right.** It controls both access and which data the user sees. By default, everyone (the **Everyone** group) has **Access** to the units they are tied to.
    
-   **Administrators** by default have the full set of rights on the top organizational unit.
    
-   **Allow vs. Deny:** An explicit **Deny** wins over an inherited **Allow**.