When creating assessments for users it is often useful to be able to associate a user with some sort of group entity.
Groups take many forms and can come together formally or informally. As such they can be characterised in a multitude of ways.
A user created by the PfP API might, as in the real world, be an individual end-user/customer, or, they may be part of a company, a member of a group such as an internal department, a team – the list could go on.
PfP recognises a defined set of group types and allows the API consumer to create its own hierarchy of groups of any type within that set.
When PfP references a group, it is referencing any type of grouping of individuals, from government bodies to companies to informal teams.
There is no requirement to use PfP’s group types, but there are advantages to doing so.
Advantages of associating users to PfP group types
By default, as a PfP API consumer, you are represented in PfP data as an Organisation entity. Not to be confused with any other type of “organisation”.
- If, in the course of your own business enterprise, you are delivering some sort of assessment services to other downstream businesses, teams or groups, but you do not create entities in PfP to represent these, then all your individual users will be associated only with your organisation.
- If you want to create assessment assignments where people can assess groups that they belong to, or groups they observe from a distance, then you will need to define a group in PfP, using a PfP group type.
- Surveys and reports involving groups are presented to the reader with we and they pronouns.
- Assignments referencing individuals use he and she pronouns
- By associating assignees and assignments with group types, you as the API consumer can access anonymous norms derived from results gained outside your top-level organisation.
PfP Group Types
When creating groups or defining users, the Group type code must be passed.
|Group type code||Description|
|AD_HOC||Ad hoc group|