Roles, data access, and approvals

People and payroll data is the most sensitive data a company holds, yet access is often granted out of habit and approvals run through chat messages. Rifena keeps the two concerns clearly apart: each person sees only the scope they are responsible for, and each request reaches the right approver with a full trail. You keep control without giving up speed.

At the end of this stage, representative users see only their intended data and a sample request reaches the correct approver.

Before you begin

Owner: an organisation administrator. The owner of each business process should help verify the result.

The organisation structure and positions should already exist. Prepare a list of who performs each job, whose data they need, and who covers an absent approver.

Choose or create a role

Path: System → Settings → Open roles and permissions.

1. Review an existing system role before creating a new one.
2. If the work requires a distinct role, choose Create role.
3. Enter a clear Role name, choose only the permissions required for the job, and keep the role Active.
4. Choose Save and wait for the saved state.

A role answers “what may this person do?”. Data access answers “whose data may they do it with?”.

Grant the role with the right data access

From the selected role, choose Grant this role…, or open Granted assignments and choose Grant new assignment:

1. Select the employee, position, or group receiving the assignment.
2. Select the Role.
3. Select the narrowest suitable data access:
   • Organization-wide — eligible data across the organisation;
   • By group — only the selected groups, with optional descendants;
   • Self only — the recipient’s own data.
4. For By group, select the groups and check Include subtree carefully.
5. Choose Grant role, then confirm the assignment appears in the list.

Use Organization-wide only when the responsibility genuinely covers the whole organisation. For a department manager or regional HR owner, prefer By group.

Verify access before configuring approvals

Ask a representative user to sign in again and confirm:

• the navigation contains only the functions they need;
• lists contain only employees or groups within their responsibility;
• the required business screen opens;
• records outside the assigned data access cannot be opened.

Correct the assignment before configuring Open approval workflows if any result is wrong.

Packages and the default way of approving

Workflow Studio is its own module, included from the Professional package. Without it a company cannot design custom workflows, but every request is still approved through Rifena’s default approval.

How default approval works

Each request type has its own approval permission. Whoever holds it, within their data scope, approves directly on that feature’s screen; there is no multi-step chain, branching condition, deadline or escalation. The Open approvals screen only lists requests that travel through a workflow built in Workflow Studio.

Request	Who approves without a custom workflow
Leave	Whoever holds the leave approval permission in the granted scope, usually the direct manager or HR
Overtime	Whoever holds the overtime approval permission in the granted scope
Shift change	The request waits in progress until someone with the shift-change approval permission acts
Advances, expense claims	Whoever holds the advance or expense approval permission in the requester’s primary group
Payroll run	Whoever holds the payroll-run approval permission
Salary payment	Whoever holds the payment update permission company-wide
Tax exemption	The request waits in progress until HR with the exemption approval permission acts
HR lifecycle event	Applied as soon as someone with the create permission saves it; types that need review, such as a contract conversion, stay as drafts for HR
KPI	Whoever holds the KPI approval permission

To decide who may approve what, grant the right permission and scope in the role assignment above. That is all the Standard package needs.

With Workflow Studio

You design a workflow per request type as described in the next section: several steps, conditions, approvers by person, role, position or direct manager, deadlines, delegation and escalation. Once a workflow is active, requests of that type follow it instead of the default approval. Active workflows keep running if a later package drops the module, but you can no longer edit them or create new ones.

Create an approval workflow

This section needs the Workflow Studio module; if your package does not include it, skip it and rely on the default approval above.

Once access is correct, follow the workflow library and builder guide to save a draft, add or insert steps, check the sequence and activate the saved configuration.

Agree on approvers, applicability conditions and timeout handling with the process owner. Off means the workflow is not enabled for new requests. Activate it only after saving and checking the configuration. Review pending requests before turning off an existing workflow to change its order.

Run one sample request

1. Use a test employee account to submit a request of the configured type.
2. Confirm the request enters a pending state.
3. Use the expected approver account and select Open approvals.
4. Confirm the request appears, review it, and make the agreed test decision.
5. Return to the sender account and confirm the final state.

If the request reaches the wrong person, check that the workflow is Active, then review its conditions, step order, approver role, and data access. Do not send duplicate requests until one concrete condition has changed.

Next step: Configure time and attendance policies, then repeat the test with leave and overtime.

If a user cannot see the expected request, screen, or in-scope action, see Access and notification problems.