Almost every record in the system belongs to an organisation, and this determines who has access to it. Organisations are arranged in a hierarchy with a reserved organisation (called Top Level ) owning everything else. Only ReallyCare / Data Controller system administrators can update this organisation, and they create a sub-organisation for every company that uses the system. Although other users cannot update Top Level, they can see it here (or by searching for it in the search bar).
Every user belongs to an organisation, and can only create and modify data that belongs to that organisation and any organisations below it. They can also see organisations higher up the hierarchy. We will illustrate with some examples for a company called CareCo. The organisation has been created by ReallyCare as shown here:
ReallyCare will also set up a user for the organisation and make them an admin (which means they can create more users).
In this example, the user is called "The Boss"
and in their user record they are associated with CareCo.
The first job of the new admin user will be to complete the set up of the CareCo organisation (especially the email, which requires setting up an account at Sendgrid - since new users are sent emails as part of the process), any sub-organisations and the system users. Let's say CareCo has a structure like this:
CareCo ┌───────────┴────────────┐ Northern Southern ┌────────┴───────┐ ┌───────┴────────┐ Team A Team B Team 1 Team 2
The Boss needs to create (at least) the Northern and Southern organisations - specifying the parent organisation as CareCo. At this point they can create users (maybe Northern Mgr and Southern Mgr) and assign them to the appropriate organisations. They can then create the hierarchy below their own organisations. It is likely they would also want to create users that belong to the Teams - let's say they are A Leader, B Leader, 1 Leader and 2 Leader.
CareCo The Boss ┌───────────┴────────────┐ Northern Southern Northern Mgr Southern Mgr ┌────────┴───────┐ ┌───────┴────────┐ Team A Team B Team 1 Team 2 A Leader B Leader 1 Leader 2 Leader
Let's consider what happens when various users search for data. All users can search for "CareCo" and they will see it in the results described as a "Company"
If The Boss searches for "Team" they will see all four teams, described as "Tier 3"
CareCo <--- Company ┌───────────┴────────────┐ Northern Southern <--- Tier 2 ┌────────┴───────┐ ┌───────┴────────┐ Team A Team B Team 1 Team 2 <--- Tier 3
However if Northern Mgr searches for "Team" they will only see Team A and Team B..
...whereas Southern Mgr would see Team 1 and Team 2:
...and A Leader would only see Team A:
Care workers, like system users, are allocated to an organisation. Sometimes - when it can - the system does this for you. For instance if B Leader was creating a new care worker, the system does not need to show an Organisation select control, as the new care worker must belong to Team B. However if Northern Mgr were to create a new care worker, they would see a select with options for Northern, Team A and Team B.
Customers are treated slightly differently since the system dictates that they must belong to "leaf nodes" - organisations without child organisations. In our example, a customer can only belong to Team A, Team B, Team 1 or Team 2. A careworker can belong to, for instance, Southern, in order that they can provide care for customers in Team A or Team 2. So if A Leader was creating a new customer, the system does not need to show an Organisation select control, as the new customer must belong to Team A. However if Southern Mgr were to create a new customer, they would see a select with options for Team A and Team B. Note that Southern is not an option, as it is not a leaf node.
Many organisation fields are automatically inherited from further up the hierarchy if they are left blank so, for instance, the email signature can be set at the company level and used by all teams.