A carer sees the people they support. Not the whole caseload.
Most care software gives everyone the same login and hopes. ELSA starts every role from a considered default: a carer gets the people they are named on and the policies they are held to, and nothing else. An administrator then adjusts it person by person, down to whether they can add, edit or delete.
What this replaces today
- One shared login, or a set of accounts that all see everything because narrowing them was never possible.
- A new starter given a manager's permissions because that was the only profile to copy.
- Data protection as something an administrator has to remember, one checkbox at a time, per person.
- Somebody who left last month still having access to the whole document library.
How it works
The role sets the starting point
Owner, admin, manager, writer, reviewer, carer and viewer each begin from a written-down default. A default only ever takes away: nothing in it can grant more than the plan sells.
Adjust it for one person
Switch an area on or off for an individual, and set what they can do within it: view, add, edit or delete. An adjustment is stored only where it differs from the role, so changing the role later moves everybody who has not been given an exception.
The boundary is enforced on the server
Four checks run in order: what the plan includes, what the organisation has enabled, what this person may reach, and what they may do. Hiding a menu is presentation; these are the boundary.
What you get
The carer default, written down
No tenders, no live tenders, no social value, no reports, no document library through the assistant, and care plans limited to people they are assigned to, are named reviewer for, or are listed as a contributor on. Policies stay on, because a carer has to be able to read what they are held to.
Per-action control, not just on or off
Letting somebody update one thing used to mean promoting them to a role that could delete everything. Now view, add, edit and delete are separate. Taking view away takes the rest with it, because a ticked edit on something you cannot open is a setting that reads as granted and does nothing.
Branches, including staff locked to one
Documents, tasks and records can be scoped per branch, and a member of staff can be tied to a single branch with no way to see or write to another.
Roles are named the way your service names them
The role most systems call a user is called a carer here, because that is what everybody in a care setting calls that person.
What stops it going wrong
Administration is not a switch
Administration, billing and analytics come from the role and nothing else. If a per-person toggle could grant them, anyone who can open the access sheet could promote a carer to an administrator of your organisation: privilege escalation dressed up as a checkbox.
A setting can never exceed your plan
Per-person settings adjust within what the plan and your organisation already allow. Nothing stored against a person can widen it, by construction rather than by policy.
Restricted access fails closed
Where the system cannot confirm which people a carer is allowed to see, it shows none, the opposite of how most lookups in most software behave, and the right way round when the alternative is exposing a caseload.
A record you may not open looks like one that does not exist
No distinct forbidden message, because that message confirms the record is there.
Who it is for
Every plan. A second branch needs Pro
For any service with more than a couple of staff, and for every service that has to answer a data protection question about who can see what.
Staff accounts are unlimited on every plan. What a plan sets is how many people you support: 25 on Core, 50 on Pro, 100 on Growth, and extra capacity can be added on top.