Test HR Software Permissions Before You Choose
Plan a role-based HR software demo using synthetic records. Separate view, edit, and approval evidence with a fictional example and blank test log.
Separate view, edit, and approval evidence
HR software permissions decide who can see, change, or approve a record. A demo of one action — say, viewing a team contact note — does not prove the same role can edit or approve the final entry. This buyer worksheet helps you plan a role-based demo, run it with synthetic records arranged by the provider, and record what was and was not demonstrated for each separate action.
This page is published by HR Co-Pilot and is a public buyer worksheet, not an app feature, not a security audit, and not a compliance certification. The authorized vendor demonstrates permissions in a provider-arranged demo using synthetic records; you record observations. Do not use real sensitive employee data, create credentials, or change real access to run this exercise.
The text below is selectable — copy the test-record labels into your own document. This worksheet has no data-entry controls.
- 1.Fix the role and the record scope before the demo.
- 2.Ask the provider to arrange a synthetic demo with labels.
- 3.Test view, edit, and approval as separate actions.
- 4.Record what was demonstrated — and what was not.
Examples from official product pages
These are attributed descriptions of official product and help pages, not an independent test or a guarantee of current entitlements. Confirm the exact plan and contract before relying on any access setting.
BambooHR describes a 'preview as user' option and multiple access levels for controlling who sees and edits records. Confirm the current product and plan for your needs; this is a vendor description, not a guarantee that access levels reduce errors or cover every permission your team requires.
Auris help center documentation describes roles and full, restricted, or organizational access, with multiple roles assignable. The article appears under Acrisure branding on the Auris help domain. Confirm available roles and scope in the current product and plan.
What to confirm in one role-based demo
Each test isolates one action and names the evidence to request and the open question — not instructions to change real access. The sample observations shown here are fictional, written for this page; they are not an actual vendor result or a pass/fail verdict.
Role identity and session confirmed
Role: Supervisor (Team North, fictional)
Record scope: Own signed-in session
Expected result
The signed-in user is confirmed as the assigned supervisor role for Team North.
Observed result
[To confirm in the provider-arranged demo]
Evidence to request
A provider-arranged test session showing the role label and team assignment.
Open question
Does the session reflect the exact role and team assignment you intend to evaluate?
Own team vs other team scope
Role: Supervisor (Team North, fictional)
Record scope: Team North vs Team South contact records
Expected result
In this fictional requirement, the Team North supervisor sees Team North contact records; Team South records are outside that role's agreed scope.
Observed result
Team North record (Sample-North) visible; Team South access not demonstrated in the demo.
Evidence to request
Ask the authorized provider to demonstrate the agreed restricted result using synthetic records — no bypass and no private URLs.
Open question
Which records are in scope for this role, and which are excluded by plan or configuration?
View vs edit
Role: Supervisor (Team North, fictional)
Record scope: Team North draft contact note
Expected result
The supervisor can view the Team North record and edit a draft contact note.
Observed result
Viewing demonstrated; editing a draft contact note demonstrated.
Evidence to request
A draft contact note opened and edited in the synthetic sample.
Open question
Does edit access apply to the draft note only, or to the full record?
Edit vs approve
Role: Supervisor (Team North, fictional)
Record scope: Final team directory entry
Expected result
In this fictional requirement, the supervisor may edit a draft but may not approve the final entry.
Observed result
Editing demonstrated; approval not demonstrated.
Evidence to request
Ask the vendor to show the appropriate approval owner and any restriction on the supervisor role using synthetic records.
Open question
Who owns approval of the final team directory entry, and is that action in the plan we evaluate?
Repeat the same approved test after a configuration change
Role: Supervisor (Team North, fictional)
Record scope: Final team directory entry approval
Expected result
After the vendor explains a configuration change, repeat the same approved test to confirm the change.
Observed result
[To confirm in a second provider-arranged demo — demo only]
Evidence to request
A second provider-arranged demo of the same test after the vendor explains the change. No bypass and no private URLs.
Open question
What changed, and does the repeat confirm the intended scope?
Team North and Team South — contact-only dummy records
The case uses two fictional teams and contact-only dummy records — no real employees, no personnel, pay, bank, tax, or medical data. A Team North supervisor is expected to view the Team North contact record and edit a draft contact note; approval of the final team directory entry is a separate action. In the demo, the Team North record was visible and editing was demonstrated; approval was not demonstrated.
Observed: the Team North contact record (Sample-North) was visible to the Team North supervisor.
Fictional illustration — written for this page, not a live product result. A demonstrated view or edit does not prove the other actions; approval remains an open question.
One entry per permission test
The field labels below are selectable — copy them into a spreadsheet or document. There are no input fields and this worksheet has no data-entry controls. Leave any field open until the authorized owner confirms it.
Permission test entry
Test
[Test name and number]
Which of the five tests this entry records.
Role
[Role tested in the demo]
The role the provider arranged the synthetic session for.
Action
[View, edit, or approve]
The single action this test isolates.
Record scope
[Records in scope for this role]
Own team, other team, or organizational scope.
Expected result
[What the test should show]
The result you arranged the demo to confirm.
Observed result
[What the reviewer saw in the synthetic demo]
What was demonstrated — not a product verdict.
Evidence requested
[Synthetic sample or session shown by the provider]
The provider-arranged evidence, with labels not real data.
Open question and owner
[Unresolved item, owner, and next decision]
What stays open, who owns it, and the next step.
A pending edit-vs-approve entry
The following describes a fictional case written for this page. It contains no real employee data and no computed result. The entry stays open — not a pass/fail vendor verdict — until the approval action is demonstrated and confirmed.
Test
4 — Edit vs approve (fictional illustration)
Role
Supervisor (Team North, fictional)
Action
Approve
Record scope
Final team directory entry (synthetic)
Expected result
In this fictional requirement, the supervisor may edit a draft but may not approve the final entry.
Observed result
Editing demonstrated; approval not demonstrated.
Evidence requested
Ask the vendor to show the appropriate approval owner and any restriction on the supervisor role using synthetic records.
Open question and owner
Who approves the final team directory entry, and is it in this plan? — People operations coordinator (fictional). Status: Open — cannot conclude the action is allowed or denied until the vendor demonstrates it.
An open question with a named owner is the useful outcome — not a product verdict. A pending field is better than a guessed answer everyone assumes was checked.
Ask before relying on a permissions demo
These are questions to confirm with the provider — not instructions to create credentials, bypass permissions, change real access, or use private URLs.
- 1Which roles and access levels are available in the plan we evaluate?
- 2Can we preview the demo as a specific role with synthetic records arranged by the vendor?
- 3Which records are in scope for each role — own team, other team, or organizational?
- 4How are view, edit, and approval actions separated, and who owns each?
- 5What configuration changes affect scope, and how do we repeat a test after one is explained?
- 6What does the written quote and contract include for permissions, access, and security terms?
HR Co-Pilot offers plain-English HR question help and policy, handbook, and letter draft starting points that require human review. This public worksheet is not an HR Co-Pilot permissions feature; confirm any provider permissions and plan scope directly with the vendor.
Related resources
Pair this checklist with the comparison hub and the BambooHR and Auris guides.
Common questions about permissions demos
HR clarity to your team today.
Ask everyday HR questions and draft a starting point to review with HR Co-Pilot.