STOREBASE INSIGHTS · Team management
Store access permissions: separate viewing, entry and approval
For multi-location stores, define employee permissions by location and action, not job title alone. Separate viewing, entering and approving information. This avoids both unrestricted access and a workflow where every ordinary decision returns to the owner.
On this page
Trust is not the same as access
A trusted employee may still have no operational reason to see another store’s payroll or purchasing information. Conversely, blocking routine work encourages people to borrow the owner’s account. Shared accounts make it harder to establish who performed an action.
Build the matrix around real tasks
| Task | Scope | Actions to distinguish |
|---|---|---|
| Sales entry | Assigned store | Entry, cancellation and refund |
| Goods receipt | Assigned location | Quantity confirmation and cost changes |
| Closing review | Specified stores | Viewing, approval and correction |
Test with the actual employee account. Can it open another store’s information? Can it change an amount? Where does an exception go? Assign responsibility for changing access when someone transfers, changes roles or leaves.
In Storebase, open a role’s permission category and check which work it can access before you save the change. That makes responsibility explicit for the team; test the employee account afterward, because this screen alone does not prove every restriction is enforced.
Delegate without losing the boundary
After granting access, review a limited sample of real transactions. Do not assume a software role supports every action in your matrix. Where controls are unavailable, document a separate approval step rather than quietly granting administrator access.
The purpose is not to restrict every employee action. It is to give people the information and authority they need while protecting sensitive changes. That lets the owner stop serving as the approval queue for routine work.
Add data sensitivity, decision ceiling, and duration to every row
A task-and-store matrix is incomplete if it records only whether an action is available. For each row, state the data object, location scope, permissible operation, sensitivity class, business decision ceiling, required evidence, approval path, and expiry condition. Entry, review, approval, correction, reversal, export, and permission administration are different operations even when they appear near one another. Include an explicit “not needed” outcome so access is not inherited merely because a broad job title sounds senior.
Tie each grant to a work reason and a named owner who will revisit it. Temporary coverage, training, investigation, and permanent responsibility should not share an indefinite permission. Where the software cannot express a narrow business limit, document the compensating procedure instead of pretending the matrix has been enforced technically. This makes a gap visible before someone borrows an administrator account to finish a routine task.
Review dangerous combinations, not just individual permissions
Two permissions that are reasonable separately can remove an important check when combined. Examples include creating a sensitive record and approving the same record, changing a value and dismissing its exception, executing a payment and performing the final reconciliation, or granting access and reviewing one's own grant. The exact conflicts depend on the store's workflow and legal duties; map them against real tasks rather than copying a universal segregation chart.
For each incompatible combination, choose a control: split the roles, require independent review, limit duration, restrict the location, or produce an exception queue for a different person. Then test a harmless fixture that attempts the combined path. If one employee must hold both permissions during emergency coverage, record who authorized it, what activity will be reviewed, and when the temporary grant ends. The point is not suspicion. It is ensuring that an error or misuse can be detected without making the owner approve every normal entry.
Re-certify access from the employee account
Run a joiner-mover-leaver cycle as a regression test. Create or use a controlled employee account for an assigned store, verify the required view and action, attempt a prohibited location and sensitive operation, then change the role and repeat. Finally, remove the assignment and confirm that unfinished work has a new owner before access disappears. Keep the test result with the matrix row, not only in an administrator's memory.
Storebase role settings visibly support reviewing permission categories for a role before saving. The evidence does not prove enforcement across every screen, transaction route, export, cached session, or existing account. It also does not turn technical access into authority to make a commercial, payroll, or accounting decision. Use the settings to implement what can be expressed, then verify from the affected account and retain a separate approval step for unsupported boundaries. The result is useful when staff can complete authorized work while the owner receives only defined exceptions and periodic access reviews.