How to manage irrelevant profile values [editor]

In numerous situations a user set profile value can become irrelevant.

Example

In a mortgage application information about the applicants' incomes are needed. One of the incomes was entered as permanent contract full time, but turned out to be a pension income. The fields belonging to the full time contract are on screen and are user set present in the profile. 

The user changes the value of field Income type from Wage labor to Pension income. Both the fields Profession and Gross salary are no longer visible on screen. A new field becomes visible Pension Income. The user enters a value for this new field.

Although the values of the fields Profession and Gross salary are not visible nor required anymore, they are still present in the profile. They might not do any harm, but saving them in a database to be collected later or when the profile values are used in a data mapping to another system, could cause problems. 

The example above illustrates what is meant with irrelevant profile values. Question is, are they problematic?

When do irrelevant profile values become a problem?

Irrelevant profile values are not always a problem. For instance, if only a document is generated and the document contains the same conditions as on screen. Or, when irrelevant values will not be processed by or saved to another system. Or, when irrelevant values are not used in any calculations or other logic etc. Hence, not every application has to deal with irrelevant profile values and if there are no conditional fields it might even be possible they never occur. 

Manage irrelevant profile values

There are multiple ways to deal with irrelevant values.

1. Clear irrelevant values with a (sequence of) service call(s)

   When clearing irrelevant values can wait until the page is left, for instance when navigating to a next step in the application, you can model a service call or flow to clear irrelevant values using the Instance_Update service type.  An example is shown below. Field Income type determines which fields are cleared in the conditional node. You could use sub flows containing the Instance_Update service calles as in the example below or service calls directly. As in the example above Income type has been changed from Wage labor to Pension income, which will result in clearing all values for specific fields for Wage labor and for instance Freelance. Any general fields, possibly a starting date or duration, will remain unchanged. 

   Example flow

   

   Example Instance update service call

   

   Create reusable expressions to use in preconditions on your page and in the clear irrelevant values flows. 

2. Clear irrelevant values with a Flow on Refresh container

   When clearing irrelevant values cannot wait until the page is left, for instance when the values are used in calculations on the same page, e.g. a calculation of the test income, you can model a service call and flow to clear irrelevant values using the Instance_Update service type and call this flow with a FlowOnRefresh container type. Often however this will not be necessary when using the correct logic in the expressions, making it more robust. 
   
   

3. Keep irrelevant values and deal with them in the application's logic

   In some situations it might be possible to keep the irrelevant values and use logic to determine whether or not they will be used in any logic or calculation, will be used in any datamapping or will be saved. For instance, in the example above you could model your application in a way that Profession will not be saved or used in a datamapping when Income type is not Wage labor. In some situation you might even want to keep the irrelevant values as long as possible to not frustrate the user when he changes his mind to prevent him from having to enter all information again.