One of the features of the organisation hierarchy that Plait employs is that options chosen at a high level of the "tree" are inherited by organisations further down the tree.  This means that your top level organisation will initially inherit all of the setup of the system Top Level organisation (which ReallyCare CIC control).


Any corporate standards you wish to enforce should therefore be applied to your top level organisation (which will appear as a Company in the search results).

(The inheritance of these organisations is shown below)

and they will be inherited by any organisations lower down the tree (which appear as Tier x).  For example, if you select the Care Worker Description on the UI tab to "Carer" in Demo Care and leave it blank in all the Tier x organisations, then the system will use "Carer" everywhere.  But if you set that field to "Care assistant" in the Supported Living organisation, then you will have "Carers" in Demo Care, Northern Area and Southern Area and "Care Assistants" in Supported Living and The Hawthorns.


Internally Plait uses a construct which we call the "Effective Organisation", constructed by ascending the tree from the organisation you are working with until all fields in an organisation record have been populated.  So in the example above the Effective Organisation for Southern Area will have a Care Worker Description value (of Carer) taken from Demo Care.


There are a couple of wrinkles to this inheritance that are worth further attention:


Tariffs

All the fields on the Tariffs tab are mostly treated as a single field, so if you have a Motoring Expenses Rate of 0.40 at the Demo care level, but Supported Living has a tariff structure with no value for that field, then no motoring expenses will be generated for Care Assistants in Supported Living or descendant organisations.


An exception to this is where the pay grid is blank at a low level organisation which has a tariff structure defined.  The system will then work up the tree until it finds a populated pay grid and use that.  This enables pay rates to be standard across a branch of the tree, while charging can vary.

Third Party Systems and "Insist on Location Permission" fields

While the inheritance works in the way you would expect dealing with fields that have a value, these fields have meaning where there is no value.


In the case of the Third Party Systems fields when the field is unpopulated it means that the Plait functionality should be enabled.  In the case of the Insist On Location Permission field when the field is unpopulated it means that the care worked can refuse to grant location permission in the Plait Point of Care app without it preventing the app from working normally.


The internal Top Level organisation has no value set for any of these fields, so by default all Plait functionality is enabled by

default, and a care worker who refuses to grant Location permission will still be able to use the Plait Point of Care app to check in to a booking.


Let's think about the Third Party Systems fields, which are unpopulated at the Top Level (as shown below)


Consider the situation where Demo Care chose to implement the system using their existing paper-based care planning system.  Setting that value at the Demo Care level will, as expected, mean that the Care Planning functions are not available for any of the organisations in the Demo Care tree.  


Once the system is running smoothly they decide to start a phased roll out of Plait care planning, starting with Southern Area.  If they set the Third Party Care Planning System field to empty at the Southern Area level then they will not get what they expect, and care planning will still not be enabled for Southern Area clients.  This is because the system starts at Southern Area and walks up the tree looking for a value in the field, and if it finds one, it uses it.  This means that the effective value for the field will be the "Paper Based" value set at Demo Care.  What needs to be done is for the field to be set to blank at Demo Care, and "Paper Based" at Northern Area and Supported Living (which will be inherited by The Hawthorns).


A similar problem can arise with the Insist on Location Permission field.  If the field is set to true at the Demo Care level, then the team manager of Southern Area cannot override that setting (because a non existent value is ignored when generating the effective organisation).  The solution here is for the team manager of Southern Area to ask the administrator at the Demo Care level to unset the field at the demo care level, and set it at the Northern Area and Supported Living organisation levels.


Array Appending

This is used for the following fields: 

  • Org Calendar 
  • Cancellation Scenarios
  • Grade Groups
  • Grades
  • Contract Groups
  • Contracts
  • Event Type Groups
  • Referral Formats
  • Training Types
  • Employment-Related Documents and other HR Activities
  • Required Documents and other HR Activities
  • Training Requirements
  • Observation Scopes
  • Default Client Review Requirements and Maximum Intervals
  • Default Care Worker Review Requirements and Maximum Intervals


This type of inheritance adds the values set at lower level organisations to those found at higher level organisations.  This works well in the situation where all levels of an organisation operate in the same way (as everything can be set at the Company level) or where organisations introduce requirements further down the tree (perhaps because of some specialisations such as complex care).  In other scenarios these fields can be left empty at the Company level and only populated further down the tree.