Roles, access, and account security

Access management in Rifena has three distinct layers:

1. A Role determines what a user can do.
2. A Scope determines whose data they can view or act on.
3. Sign-in and account security determine how the user proves their identity when entering Rifena.

Seeing the right menu is not enough to prove access is correct. This journey is complete only when the person can perform the required work, sees data only in the granted scope, and cannot perform actions outside their responsibility.

Role owner: organisation administrator.

Delegated grant owner: group administrator, but only for roles and groups allowed by the screen.

Company sign-in owner: an administrator working with IT.

Every user: manages their own passkeys, two-step verification, and notification preferences.

Separate the role, subject, and scope

Part	Question it answers	Example
Subject	Who receives it?	An employee, group, or position
Role	What can they do?	View attendance, approve leave, manage payroll
Scope	Whose data can they act on?	The organisation, selected groups, or self only
Validity	How long does it apply?	Indefinitely or until a project ends

Menu visibility does not prove data access

The menu is only an entry point. Each action checks the user’s role and scope. After granting access, open the target area with a representative account and test both the visible data and the permitted actions.

Part A — Create and maintain roles

Open Settings → Roles & Permissions. The page has four areas:

• Overview: totals and quick entry points;
• Role management: create or edit roles;
• Assignments: see who holds which role, over what scope, and until when;
• Audit log: review grant, revoke, and deletion history.

1. Prefer an existing role

Under Role management, find an existing system or custom role. Open it and review permissions in each business group.

Create a role only when none of the existing roles reflects the real job. An overly broad role is difficult to control, while many nearly identical roles are difficult to review. Prefer a role with a clear purpose and only the permissions needed for that work.

2. Create a role when necessary

1. Select Create role.
2. Enter a business-facing Role name, such as “Southern attendance manager”.
3. Enter the Reference code; it cannot be changed after creation.
4. Select permissions under System administration, Operations & approvals, and Self-service.
5. Turn on Delegatable if group administrators may grant this role. A delegatable role cannot contain organisation-level administration permissions identified by the screen.
6. Review the unsaved-change count and select Save.

To prevent future grants, make the role Inactive. A role with historical use usually needs to remain for audit continuity; do not delete it merely to shorten the list.

Part B — Grant the correct subject and scope

From Overview or Assignments, select Grant new assignment.

1. Select the subject

• Employee: use for a named person, especially an exception or time-limited responsibility.
• Group: applies to current and future members of that group.
• Position: follows the position in the organisation; its configuration remains when the person holding it changes.

The subject determines who receives the role; it does not replace data scope. For example, selecting one employee can still give that employee access across the organisation if the next step is too broad.

2. Select the role

Select an Active role. If only some roles are available, the current account may be allowed to grant only roles marked Delegatable.

Read the role’s maximum-scope warning. If its permissions require a different scope, Rifena will not save an incompatible combination. Correct the role or choose the intended scope; do not select an arbitrary option to bypass the warning.

3. Select the data scope

Scope	The recipient can work with
Organization-wide	Data for the whole organisation; use only for genuine organisation-level responsibility
By group	Selected groups, with optional Include subtree
Self only	The recipient’s own data; suitable for self-service

For responsibility over one branch, select the exact group and decide whether to include child groups. With a Group subject, the screen may constrain scope according to current access; read the summary before saving. A manager working only with their branch usually needs an Employee or Position subject with By group scope, not organisation-wide access granted to an entire group.

4. Add an end date to temporary access

Under Validity (optional):

1. set Valid from when access starts in the future;
2. set Valid until for a project, temporary replacement, or transition; and
3. add Internal notes so a future reviewer knows why it exists.

For a personal exception, set an end date so Rifena can expire it as declared. Do not use permanent access for a need with a clear end point.

5. Read the summary and grant

Before selecting Grant role, read the final sentence in the dialog:

• which role;
• granted to whom;
• which scope and how many groups;
• whether child groups are included; and
• when it expires.

After saving, open Assignments, find the subject, and confirm that the role, scope, and validity appear as intended.

Part C — Test, revoke, and inspect history

Test effective access

Use a representative account for the subject, or ask the recipient to follow this checklist:

1. select the correct organisation;
2. open the required product area;
3. confirm that the intended groups or personal records are visible;
4. perform the action required for the job;
5. attempt to open a record outside the scope and confirm access is denied; and
6. record the result when the access is sensitive.

If an action is missing, check whether the role contains it. If too much data is visible, check the scope and child-group option first; do not add a broader role to compensate for a configuration problem.

Revoke access

Open Assignments, find the exact row, and select Revoke. Read the subject, role, and scope again in the confirmation dialog before continuing.

A person may receive similar access through several assignments: directly, through a group, or through a position. Revoking one row does not prove every equivalent permission has gone. Filter for the subject, review all active assignments, then repeat the representative-account test.

Read the audit log

Audit log records GRANT, REVOKED, Deleted, and related changes. Open an event to review:

• time;
• actor;
• subject;
• role;
• scope; and
• before-and-after details when present.

Use the log to answer who granted or revoked access and when. Do not use it as a substitute for the list of currently active assignments.

Part D — Company sign-in and multi-factor authentication

Open Settings → Single sign-on (SSO). The organisation can retain Rifena accounts or configure an external identity provider using OpenID Connect or SAML 2.0. This work requires coordination with IT and the identity provider.

Read SSO states correctly

State	Meaning
Rifena accounts	Users sign in with accounts managed by Rifena
Configured	Provider details are saved, but an active sign-in path is not yet proven
Active	Rifena recognises a provider that can be used for sign-in

Saved configuration does not mean SSO is usable

If the page warns that there is no active connector, employees cannot sign in through that configuration. Do not announce a cut-over or attempt to turn on Enforce SSO. Continue only when the state is Active and a test account has signed in successfully.

Configure it safely

1. Select External identity provider.
2. Set the Organization key employees will use on the SSO sign-in screen.
3. Select OpenID Connect or SAML 2.0.
4. Copy the displayed Redirect URI or service-provider details into the identity provider.
5. Enter provider details. For SAML, Import metadata, then review the populated fields.
6. Choose Just-in-time provisioning and allowed email domains when used by the organisation.
7. Choose the MFA level: Off, Optional, or Mandatory, and select the permitted methods.
8. Select Save changes and read the resulting state.
9. Test sign-in with an account other than the administrator making the change.
10. Consider Enforce SSO only after the test succeeds and the state is Active.

When an existing client secret has been stored, leaving that field empty keeps the old value. Do not enter a placeholder merely to fill the form.

Part E — Personal account security

Each user opens Account → Security.

Change the password

Open Account → Profile, find Security, then:

1. enter the Current password;
2. create a New password with at least 12 characters, including uppercase, lowercase, and numbers;
3. enter it again under Confirm password; and
4. select Change password and wait for the success message.

The new password cannot match the current one. Avoid common or easily guessed passwords; Rifena may reject one even when it contains 12 characters. Read the first error before trying again.

Add a passkey

1. Under Passkeys, select Add passkey.
2. Follow the browser or device prompt.
3. Confirm that the passkey appears in the list with its creation date.

If the device reports that passkeys are unsupported, use another available two-step method. Do not keep attempting registration in an incompatible browser.

Enable an authenticator app

1. Under Authenticator app, select Set up.
2. Scan the code, or enter the setup key in the authenticator app.
3. Enter the six-digit Verification code.
4. Select Verify.
5. Confirm that the state becomes On.

The QR code and setup key are sensitive and used only during enrolment. Do not capture or send them through a support channel.

Email and recovery codes

• Under Email code, select Enable when company policy allows it. Enter the six-digit code sent by email and select Verify email; receiving the email alone does not enable the method.
• Under Recovery codes, select Generate and store the codes safely away from the device used for authentication.
• Use Regenerate if the old set may be exposed; the previous codes are no longer the set to keep using.

Recovery codes are displayed only once. Select I saved these codes only after storing the complete set safely; closing the dialog first may leave you without a copy to verify.

The screen may state that enrolment completes only after the identity service is enabled for the account. If the action produces no result, record the displayed state and message instead of assuming the method is active.

Part F — Choose notification channels

Users have two entry points:

• open Notification Center and select Preferences; or
• open Account → Notifications.

Then:

1. find the notification type or group;
2. choose In-app, Push, Email, or Push + Email;
3. use Receiving / Paused for each type; and
4. wait for the saved-preferences confirmation.

History remains in Notification Center when a type is Paused. The switch stops real-time, push, and email delivery; it does not delete existing notifications.

Selecting an actionable notification opens the corresponding work area. A pending HR-event notification may open Approvals with the intended request already selected. Recheck the employee, request type, and state before deciding; marking a notification as read does not process the request.

If the result is not right

• Roles & Permissions is missing: the current account cannot view it; ask an organisation administrator to check.
• Cannot grant a role: check that the role is Active, the scope is compatible, and the grant owner is allowed to delegate it.
• The recipient sees too little data: check the selected group and Include subtree.
• The recipient sees too much: look for an Organization-wide assignment or another grant inherited through a group or position.
• Access remains after revocation: find every active assignment for that person, then retest with a representative account.
• SSO remains Configured: read the provider warning; it is not yet an active sign-in path.
• Cannot turn on Enforce SSO: no provider is Active. Do not bypass this safety condition.
• Push or email is missing: open Account → Notifications, check that the type is Receiving, confirm the selected channel, and inspect browser or device notification permission.
• Password change fails: check the current password, 12-character minimum, uppercase, lowercase, numbers, and confirmation. If Rifena reports a common password, choose a different, harder-to-guess one.
• Email code remains Off: reopen setup and complete the six-digit verification; receiving the message is not a successful enrolment result.
• Passkey or authenticator setup fails: record the method, service state, and displayed error for Support.

The journey is complete when

• The role contains only the permissions required for the job
• Subject, scope, child groups, and validity are correct
• The assignment appears in the active list
• A representative account sees the intended data and cannot open data outside its scope
• Temporary access has an end date and internal note
• The audit log records the grant or revocation
• SSO proceeds only after an Active state and successful test sign-in
• The personal password meets policy and the change has a success message
• Each user has an appropriate personal security method
• Recovery codes were stored before dismissing their one-time display
• Notification preferences are saved and tested on the selected channel

Continue reading

• Approvals and permissions
• Manage by organisation group
• Offboard and rehire
• Permissions by product area
• For HR administrators
• Support for access and notification problems