Understand Required Fields

Portfolio Data Center includes a workflow option to enable ‘Required field’ processing when creating or editing entities.  When setting up a new entity manually, required fields must have a value before the entity is allowed to be processed and saved in the system. The purpose of this feature is to meet the business requirement whereby some firms do not want to save partially complete entities unless a minimum set of fields are populated. A required field is distinguished from the others by the red asterisk (*) displayed next to the field name within the various user interfaces.

For example, it might be acceptable to set up and save a partially complete entity even though its Tax Status field is not filled out. This field is not considered as a required field. In this case, you can set up an entity with all its other information, saved as partially complete, and completed at a later time. However, there might be some information, which is important enough that, if missing, is not appropriate to have the new entity added to the system at all. You can consider these fields as required fields. The types of fields that would qualify for required field processing will vary from firm to firm. To complete the example, assume the entity name is required. While creating a new entity, if this field is left blank, the submit process is disabled and an alert message is thrown to the user to fill out all required fields. Therefore, new funds are not saved in the system unless all required fields are populated. Note: Required fields processing is optional.

Required Fields vs Validation 

Required field processing is a real time check within the user interface and not a validation that is processed though the PDC engine. Its purpose is to prevent users from setting up partial entities. Conversely, validations can check for empty fields but still allow for the partial entity to be saved in the system. As explained in the above section, though the Tax Status was not a required field but it still might be an important field. In this case, instead of making it a required field, you can set up a validation as ‘tax status = null’. If a new entity is set up without entering a value for the Tax Status field, PDC will create the shell entity in the database with a partial release level and generate an exception for the tax status field. Conversely, if the (required field) entity name was left blank, that is without adding a validation, then you cannot even submit the request in the first place. 

Configuration of Required Fields

There are two methods for enabling required fields processing.

• Field Level option: If you enable the Required field option at the Field level, then it is pushed downstream to all policies that contains that field. This global approach allows you to enable it once and propagate it downstream automatically.

• Policy Level option: If you enable the Required field option at the Policy level, then it is enabled only for the entities that are governed by that policy. Similarly, if the option has been enabled at the field level, thus effecting all policies, you can disable it within a specific policy without impacting the others.

Note: The Field level option is applied globally, to all the policies that contains the field, while the Policy level option limits it to the specific policies.

Legacy Entity Processing

The required field setting works in conjunction with legacy entities already set up in the system. For example, if you were maintaining entities in Eagle long before the introduction of PDC. After configuring PDC, if you decide to use required fields option, then the UI understands that existing entities may have been set up without values for what are now considered as required fields. In such cases, if you open an entity and attempt to edit a history record, at that time, PDC will check the existing record to see if it is missing values for required fields and prompt the user to fill them in.

Entities Loaded via ETL

Recall that the required field option is a real time, UI based process and not an engine based validation. As such, it will not prevent ETL (uploader, message stream, and so on) processes from loading a partial entity into the system. If your firm uses required fields and relies heavily on an ETL process to insert new entities, then the current best practice is to add a field level validation for each required field, for example ‘Entity Name = null’. This will not prevent the partial entity from being loaded to the system but it will generate an exception and set the entity release level accordingly.

On this page