Record Requirements
Introduction
The Record Requirement functionality allows to define a set of requirements that must be met for an specific records. These requirement are not validation rules, are physical requirement as Documentation to attach or other similar scenarios.
In the current version, the only Requirement type available is Document. What means that this functionality can handle the Required Documentation for any record in the system.
Data Model
There are two main objects, specifically Custom Metadata Types:
| Object | Description |
|---|---|
| Record Requirement Definition | Defines the main configuration for a specific SObject. A Record Requirement Definition has zero to many Record Requirements |
| Record Requirement | They represent each specific requirement for a SObject / Record Requirement Definition. |
Record Requirement Definition
They are used to enable the Record Requirement for a specific SObject and specifying which information should be passed to the child Record Requirement.
| Field | Type | Required | Example | Description |
|---|---|---|---|---|
| SObject API Name | String | Yes | Contact | The API Name for the SObject you want to define the requirements. |
| Object Tree | String | Yes | Contact Object Tree | The name of the [Object Tree]({{< relref “/docs/technical/core/objecttree” >}}) that will be loaded and passed to the different Requirement Rules |
In next releases it will be possible to set more than one Definition for the same SObject Type by setting a Rule that will identify which one should apply. But right now, you can only have one Definition per SObject.
Record Requirement
They represent each single requirement that could apply for any record of a specific SObject. It’s important to remark that not all existing requirements will apply to all records, as the requirement will be considered only if its Requirement Rule is met (true).
This way you can set different requirements depending on the Record properties and context. I.e: for a disconnection order would require different documentation than a Owner Change order.
| Field | Type | Required | Example | Description |
|---|---|---|---|---|
| Record Requirement Definition | CMT | Y | Contact | The parent Record Requirement Definition record for the current SObject. |
| Type | Picklist | Y | Document | The requirement Type. Only available value is Document |
| Optional | Boolean | N | true | It specifies if the requirement should be shown despite of not being mandatory. For example, for recommended documentation. |
| Message | String | N | It’s required! | The message to show to the user when the requirement is not satisfied |
| Document Types | String | Y | ID,Passport | Comma-separated list with the document types that apply to this rule. |
| Document Type Check Mode | Picklist | Y | All | – All: it requires all the items in the Document Types field to be attached. – Any: it only request on of the different items in the Document Types list. |
| Requirement Rule | String | Y | &Account.Type = “VIP” | A [Wattyo Expresion rule]({{< relref “/docs/technical/rules” >}}) that must be met in order to consider this requirement to be applicable to the current record. |
How it works
The Record Requirement functionality has three main parts:
- Configuration: Where you set for each SObject which requirements should be validated according to the specific record.
- Engine: which identify which requirements apply for an specific record based on the Configuration and evaluates them to check if they are satisfied or not.
- Lightning Web Component: used to show and managed the requirements.
The process is the following:
- When the user loads the Record Requirement LWC in a Record Page, the engine retrieve the correspoding Record Requirement Definition for the current SObject.
- It loads the defined [Object Tree]({{< relref “/docs/technical/core/objecttree” >}}) for the specific record, generating this way the context to be passed to the Requirement Rules.
- It evaluates the different Record Requirement rules to identify wich of them apply.
- When the All mode is set, and more than one Document Type is set for the Requirement, the Requirement is split into independent Requirements for each Document Type.
- For the requirements that apply (and the exploded ones) it checks if the Documentation specified by the Requirement is attached or not to the record.
- If the document is attached the requirement is set to Success=true and the record that satisfied the requirement is identified and attached to the in-memory Requirement.
- If the document is not attached, the requirement is set to Success=false
- Once all applicable requirements have been evaluated, the results are returned and shown in the Record Requirement component.
The Attachments / Documents
Wattyo uses the standard Document data model and functionality (ContentDocument, ContentVersion and ContentDocumentLink) except for one Custom Field in the ContentVersion Object named Document Type which is a Multivalue Picklist that would store the different Types that applies for a specific document.
In order to Upload a File at the same time as the user can set the Document Type, the Wattyo Upload Document LWC must be used. And this is the one that the Required Document LWC will show to the user when he clicks on the upload button.
The File Upload is done through the out of the box File Upload LWC, and once it’s successfully uploaded, the LWC controller send a simple request to set the Document Type for the just created file.
