Settings

What this achieves

Settings is where you configure the workspace itself rather than the people in it — who can sign in, what they can reach, how the product looks, and what it emails. It also holds your subscription, which decides which parts of Humavera your company can open at all.

What lives here

Option	Description
Users and roles	Who has an account, and what their role permits.
Security	Sign-in rules, including two-factor authentication and session control.
General and branding	Workspace-wide settings, and your own logo and colours.
Notifications and digests	What the product tells people about, through which channel, and how often.
Module configuration	Settings owned by a specific area, such as leave, payroll policy, or which sections appear on employee records.
Audit log	The system-wide compliance trail, queryable and exportable.
Billing and subscription	Your plan, what it includes, and your billing information.
Personal preferences	Each person’s own notification preferences, two-factor setting, and delegations.

The last row is the exception worth knowing: most of Settings is for administrators, but every signed-in person has a few settings of their own here.

Example: James Whitfield opens Settings to change his notification preferences and set up two-factor authentication. He does not see the user list or the audit log.

Roles decide reach, not only menus

A role determines what a person can reach, and it is enforced when data is requested rather than by hiding menu items. Changing someone’s role changes what the system will answer for them.

Example: giving Sophie Clarke an administrator role at HC Corp changes what she can see company-wide. Removing it takes that access away immediately, including on any page she has bookmarked.

Plans decide which sections exist for you

Humavera is sold in subscription plans, and some sections of the product are included in certain plans and not others. A section your plan does not include still appears in the navigation, so you can see what it does, but it cannot be opened until your plan includes it.

This is deliberate. Hiding it entirely would mean nobody could discover a capability they might want; showing it locked makes the boundary visible.

Two related behaviours follow. Some plans cap the number of active employees your workspace can hold. And while a plan change is being processed, affected modules become read-only rather than disappearing, so nothing is lost mid-transition.

Example: an HC Corp administrator sees a locked section in the sidebar, opens Settings to compare plans, and finds it included in a higher one.

Your plan, what it includes, your AI credit allocation, and your billing information all live in Settings. This is the one place in the documentation that explains plan gating — if a section looks locked, this is the page that explains why.

Audit log

The audit log is the compliance record: system-wide, queryable, exportable, and governed by a retention policy. It is distinct from the activity feed, which is the readable account of what is happening. Use the feed to see; use the audit log to prove.

Data protection

Settings is also where data-protection obligations are met. Humavera supports consent tracking, data-subject access requests, and erasure or anonymisation, alongside encryption and masking of sensitive identifiers held on employee records.

What happens next

Set roles and security before inviting people, because both are harder to tighten once everyone is working. Confirm which modules your plan includes before configuring a section, so you do not design a process around something you cannot open. Notification settings are worth revisiting after a few weeks, once you know what people actually want to hear about.