Concepts
Clients, Relationships & Self-Relationships
A Client within Dynamic Planner represents an individual person who is being provided a service by a financial advice firm. At a minimum, Dynamic Planner will need their name and date of birth. All other information is optional. Information that can be stored about a Client includes:
- Contact details such as address, phone numbers and email address
- Documents either uploaded to or generated by Dynamic Planner
- Financial circumstances including investments, incomes and expenditures
The Relationships between Clients are also represented in Dynamic Planner. A Client can be in many separate Relationships, for instance Client A could be in a "Marriage" with Client B, and in a "Business Partnership" with Client C. There are two important rules about Relationships:
- Currently, a Relationship can only contain two Clients
- Two Clients can only be in one Relationship with each other
Some areas of the Dynamic Planner application operate only with Relationships. To allow those areas to work with a single Client a special Self-Relationship exists for every Client. The Self-Relationship is automatically created every time new Client is created. It can only ever contain the one Client. Its identifier can be used everywhere a normal Relationship's identifier can be used.
Employees
In Dynamic Planner, an Employee is any person that works for a financial advice firm. They could be an adviser, a paraplanner, administrator etc. A licenced user of Dynamic Planner is an Employee.
When calls are made to the Open API, they are always in the context of an Employee. An Access Token created by Dynamic Planner's Identity Server for use against the API will contain the identifier of an Employee (employeeid). This is true whether the Access Token was created via an interactive login to the Identity Server or by a Client Application using the "client credentials" flow... there will always be a designated Employee.
An Employee can be designated as the Relationship Manager for a Relationship or a Self-Relationship. Generally, the Relationship Manager would be an Adviser (but can be any Employee). If a new Client record is created in Dynamic Planner, and the Relationship Manager is not specified, the Employee of the Access Token used to create the new Client is set as the Relationship Manager.
Organisation Units
Dynamic Planner represents a financial advice firm (or part of a firm) as an Organisation Unit (OU). A single OU could for instance represent a large network, a regional office of a firm or a small one-person firm. An OU does not need to represent a real entity. For example, some firms have a logical OU for each adviser within the firm.
When calls are made to the Open API, they are always in the context of an OU. An Access Token created by Dynamic Planner's Identity Server for use against the API will contain the identifier of an OU (ouid). This is true whether the Access Token was created via an interactive login to the Identity Server or by a Client Application using the "client credentials" flow... there will always be a designated OU.
An Organisation Unit can be designated as the Owner Organisation Unit of a Relationship or a Self-Relationship. If a new Client record is created in Dynamic Planner, and the Owner OU is not specified, the OU of the Access Token used to create the new Client is set as the Owner OU.
Employees are linked to one or more OUs by their Dynamic Planner licences. Because an Access Token can only refer to a single OU, Dynamic Planner's Identity Server will make any Employees linked to more than one OU pick the OU to use. a Client Application using the "client credentials" flow will use the OU configured for it in the Identity Server.
Organisation Unit Hierarchy
Dynamic Planner holds a nested Hierarchy of OUs that define how the financial advice firms are related to each other and how they are subdivided. Subdivisions are represented as Child Organisation Units belonging to the Parent Organisation Unit. The hierarchy is not limited to two layers, there can be as many (or as few) layers as needed to represent the firm.
The main purposes of the hierarchy are to:
- Allow configuration to be inherited from Parent OUs
- Enforce the visibility of only those entities belonging to the current OU and its Child OUs
Configuration Inheritance
Configuration of Dynamic Planner mostly involves a value for an item of configuration being linked to an OU. When an item of configuration is used within Dynamic Planner, the system will search up the hierarchy for the closest Parent OU that has the item configured. For example, given a configuration item called "Rate":
If an Access Token is associated with either the "System" or "Firm B" OUs, the APIs will use the "Rate" value of 80%. However, if an Access Token is associated with either "Firm A", "Office A1" or "Office A2", the APIs will use a "Rate" value of 95%.
So that the APIs (or the Client Application) can know where in the Hierarchy the OU associated with the Access Token is located, there is a Path value (oupath) included in the Access Token. The oupath consists of a series of Path Identifiers separated by back-slashes, one for each Parent OU, in depth order (the first is the highest OU in the hierarchy and the last is the current OU). For Example, an Access Token for the "Office 2A" OU below would have an oupath set to "28\31\38"
An OU's Path Identifier is a unique integer that will not change over time. The API uses the Path Identifier of an OU as a key to store items of configuration against. For example, to support the "Rate" configuration item above there would be two entries in the "Rate" configuration store:
| Path Id Key | Rate Value |
|---|---|
| 28 | 80% |
| 31 | 95% |
A Client Application can use the same approach, allowing it to store configuration data against Dynamic Planner's hierarchy without knowing the shape of the hierarchy itself. At run-time, it can extract the OU Path from the Access Token it is using to understand which OUs to inherit configuration from.
Note: whilst the Path Identifier of an individual OU will not change, the overall OU Path will change if the OU is moved within the hierarchy. So only the Path Identifier (i.e. the last integer in the oupath) should be used as a key, not the entire path.
Entity Visibility
Many entities within Dynamic Planner are linked to OUs. For example:
- Each Client Relationship and Client Self-Relationship is linked to an OU (and therefore, indirectly, every Client is linked to at least one OU)
- Each Dynamic Planner licence links an Employee to an OU (so an Employee with multiple licences can be linked to multiple OUs)
- An OU is linked to one Parent OU and can be linked to multiple Child OUs
The OU associated with an Access Token is used to narrow the scope of entities that the API will allow a Client Application to work with (i.e. which entities are "Visible"). Only those entities linked to the associated OU directly, or to one of its Child OUs, can be accessed. For example, given Clients A and B who are linked to a hierarchy by only Self-Relationships below:
Then the following will be true:
| Access Token OU | Relationships Visible | Clients Visible | OUs Visible |
|---|---|---|---|
| System | Client A Self‑Relationship, Client B Self‑Relationship | Client A, Client B | System, Firm A, Firm B, Office A1, Office A2 |
| Firm A | Client A Self‑Relationship, Client B Self‑Relationship | Client A, Client B | Firm A, Office A1, Office A2 |
| Firm B | Firm B | ||
| Office A1 | Office A1 | ||
| Office A2 | Client B Self‑Relationship | Client B | Office A2 |
If an additional Relationship is introduced between Client A and B as below:
Then the following will be true:
| Access Token OU | Relationships Visible | Clients Visible | OUs Visible |
|---|---|---|---|
| System | Client A Self‑Relationship, Client B Self‑Relationship, Clients AB Relationship | Client A, Client B | System, Firm A, Firm B, Office A1, Office A2 |
| Firm A | Client A Self‑Relationship, Client B Self‑Relationship | Client A, Client B | Firm A, Office A1, Office A2 |
| Firm B | Clients AB Relationship | Client A, Client B | Firm B |
| Office A1 | Office A1 | ||
| Office A2 | Client B Self‑Relationship | Client B | Office A2 |
Business Processes & Business Process Instances
Dynamic Planner has its functionality grouped into Business Processes to provide a user (such as an adviser or paraplanner) to have all the tools they need to complete a given task in one place. For instance, the Client Review Business Process contains the functionality for:
- Capturing information about a Client's portfolio (both at the start and end dates of the review period)
- Interpreting risk and sustainability questionnaires
- Recording Client objectives
- Detailing charges
- Analysing the Client's current portfolio (e.g. global exposure, portfolio risk, forecasting, etc.)
- Registering outcomes
- Generation of a report for the Client
The Business Processes supported by Dynamic Planner include:
- Client Review
- Client Profiling
- Recommendation
- Cash flow
- Product Research
When a Business Process that has a tangible outcome is started, a new Business Process Instance (BPI) is created. The BPI is the entity that encapsulates the data and state that is used throughout the Business Process. For example, an adviser may create one Client Review BPI every year for each of their clients.