Organisations

Almost every record in the system belongs to an organisation, and this determines who has access to it and who can update 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. 

When CareCo start using the system an organisation is created by ReallyCare, who also set up a user for the organisation and make them an admin (which means they can create more users).  For example the user might be called "The Boss" and

and in their user record they would be associated with CareCo.

The first job of the new admin user will be to complete the set up of the CareCo organisation, 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 care worker 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.

When running reports within the system, users will get to see results that include all organisations from their current level downwards.  So in our example above The Boss would get to see data from 7 organisations, whereas Southern Mgr would just get to see data from 3.

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.

It a user logs in at a level that has children organisations, then they can Switch Context to focus one a specific area of the hierarchy.

There are more details FAQS dealing with how organisation hierarchy works with system setup / module selection and   invoice / pay advice production.