In this article I am going to explain on why I generally use a table instead of a choice for options. Let’s assume that we are building a travel booking app. With each booking we want to capture the transport type. We can simple use a choice with all the available options. However, there are some issues with this approach. What happens if you want to add new options or update existing options. This would require a user with the specific security role to go on to the power apps maker portal and perform the required changes and publish. Now consider the scenario where one of the options is not needed anymore and needs to be removed from the choice list. What if the choice is being used by other columns in other tables. Those columns may need all values in the list? What happens to the records which had the choice value selected that you now want to remove from the list? What about de-activated records? There are so many questions and problems. Let’s find out the answers with the help of an example.
We have a simple travel booking app. For back-office support we have a mode-driven app while the sales staff use the canvas app on mobile as they are in the field looking to sign new customers. We have a choice named “Season” and a table named “Transport Type”. As can be seen below: I have one active and one in-active record for Travel:
Let’s assume that “Summer” option is no longer needed for the Season field. Since it is a choice, I can go in and remove this option. After removing the option, the above two records now display the below information:
Notice that since the “summer” option is removed, both the records now have no value for “Season” field. This is an issue because now the historical inactive record is wrong. To fix this issue, the easiest approach is to use a table instead of a choice. A table is used for transport type. Let’s remove the “Car” and “Train” records from the table. To preserve Travel records, we can de-activate the car and train records instead of deletion. After de-activation, the above two records now have the following values:
Notice that even after de-activation, the current records display the values and ensure record integrity. The advantage of using the table approach for options is that these tables can be exposed to the users in the model-driven app as part of a configuration or settings menu. A user can then add, update or de-activate records as needed without the need to engage a user with specific security role and publish. Another advantage is that this table records display as a drop down list on canvas app so there is no compromise on user experience on the canvas app.
Hope this helps in designing maintainable solutions.