My latest project is a big one – a large database divided into several key modules with each module managed by a dynamic dashboard. The dashboards allow users to search selected records based on a wide variety of criteria. The dashboards also allow users to create new records without leaving the dashboard. They can navigate to records in sub-Tables and then return to the dashboard again to continue working in the selected module. I thought this design a good one until a problem was reported by test users: While working in the dashboards, one user could “control” what another was seeing and doing. For example, it might be impossible for a user to select a search criterion when another was using a different criterion. Users couldn’t understand what was happening and actually wanted to give up using the new database. At first, I didn’t understand what was causing this terrible problem, either. Each user used a different login and should be able to work without having any effect on another user. After someone explained it to me, however, the cause seemed perfectly obvious.
Let’s look more closely:
When a user fills in fields or selects options from choice fields on database table forms, the data on that form has been changed. The change is synchronized between users so that all users see the latest updated information. Normally this doesn’t cause confusion because two or three users are unlikely to be using the same record in the same table at the same time. A dashboard is in essence a table form like any other. Given my database design, which is dashboard intensive, they get heavy use and are likely to be used by two or three people at the same time. Therefore, changes made by one user were actually influencing what the other users experienced, creating frustration and general bafflement.
I didn’t want to change the architecture of my database, and removing the editable fields from the dashboards would render them useless. I needed a solution that would allow multiple people to use the same dashboard at the same time – without making any design change to the database or to the dashboard.
Here’s how I did it:
First, I created a new field on my dashboard: a user type of field. User fields allow for the selection of any current user on the database team as a field choice. The default name for the new field was “User” and I left it at that. Next, while still working in admin mode, I selected the first user in the list as the selected user. Then, I used the Duplicate Record button in the upper right corner of the form to duplicate my dashboard. Working in this new record, I selected the second user in the list in the User field. I repeated this until I had one record for each user in the team. Note that each user’s dashboard is an exact duplicate of the original dashboard. The only difference was the chosen value in the User field. Finally, I hid the User field on the dashboard by typing the word “null” into its “Display Only If” function.
Now I had several versions of the same dashboard – each one a “record” in my module table. Each dashboard was linked via the User field to a specific user and every user had their own edition of the identical dashboard. The final step was to ensure that each user would be directed to their own dashboard when navigating there. This requires a couple of lines of code:
let xUser := user(); let j := first((select 'EVENT MANAGEMENT')[User = xUser]); openFullscreen(record('EVENT MANAGEMENT',j))
This code block directs the user to a dashboard named “Event Management”, not just a regular dashboard, but their own edition of the dashboard, and opens it in Full Screen mode. (If you prefer not to use Full Screen mode, substitute another function in line 3.) This code can be used in any field that has an “on click” function. In my case I had an icon in the gateway form of the program that allows users to direct where they want to go in the database by clicking the icon that represents a module.
Figure 2 shows the result of the formula field used to display my icon for the “Event Management” module. To insert an image into a formula, store the image somewhere in the database and then refer to it in the formula. If you store the image in a table named Icons, and your image is named Events, then insert the image into the formula field using this formula:
Then insert your navigation code block into the “On Click” event of the formula field and you’re ready for action! I modified each module’s dashboard in my database to this multi-user mode and users can now work completely independently in the database dashboards without affecting what any other user is doing. This didn’t take long to do, and it will pay huge dividends for user confidence and ease-of-use. You might try this method for any table form that gets heavy use by multiple people at the same time – not only dashboards but any type of form that’s central to your database’s architecture.