What's new in Houston
April 2023
Conditional display
With Conditional Display (available to administrators in object editing mode), you can choose to display or hide a form element based on the value of another field, and even based on the role of the user (more on roles further down this article).
You can combine criteria, for instance:
If field <Status> = Done AND team = Berlin then display tab <Archive>
This feature will gradually include more options for display, such as filtering the content of a dropdown
User roles and access rights
Roles are an important concept in Houston as they will allow processes to be applicable to other contexts / teams.
Roles can be assigned to teams or to individuals and are used:
- To grant access rights (who can create, edit or delete records of an object)
- In conditional displays (for instance: only role “Approver” can see tab “Validation”)
- In automations (for instance: send an email to Quality Management Team for every new Non-Conformity)
There are default roles (editor, creator) that must be assigned in order to grant the corresponding access rights.
There are user-defined roles, which are created in the context of an object. For instance, “Approver”, or “Safety coordinator”, etc.
Finally, there are dynamic roles, e.g. “Record author” that are not assigned to a specific team / user but are assigned dynamically depending on the context.
You can already use roles for your Houston objects but we have to create them for you as the role management user interface is not deployed yet.
Access rights
Whenever an object is published within a team, all team members get Read (only) access to the records of that object (only those created in that team of course).
The other access rights (create, edit, delete) are granted through roles by the administrator of the team in which the object is published.
Teams hierarchy
Large organizations include multiple layers, which are necessary in the management of data and process deployment.
Houston now includes the possibility to create multiple levels of teams.
The key benefit is that each team can access different Houston objects, with different access rights.
The team hierarchy is displayed in the viewpoint selector (in the top navigation bar) and allows to filter / consolidate data based on the currently select team.
Of course, a user belonging to a sub-level team will only be able to see records that have been created up to his level, not above.
A user from a high-level team will be able to see all content from his team downwards, and filter on any sub-team.
In the near future, team hierarchy will also be the basis for object version management, allowing to customize Houston objects within each team.
Home page filtering
User home page now only displays the objects that are available to the users of the team in the viewpoint selector.
Admins can have a global view by selecting “All teams” as viewpoint, or can see what specific team members see by selecting the related team.
The viewpoint shows the team last selected. This selection is remembered event after logout.
Content filtering based on viewpoint
The viewpoint selector at the top of the screen determines what you see below.
This is true in particular when looking at object data, where you only want to show the records from a particular team. Of course, if a user only belongs to a lowest-level team, he won’t have the possibility to change his viewpoint.
But higher-level users or admins can select another viewpoint and get a broader or narrower view.
Referential objects
As an organization, you sometimes need to manage a shared list of items that will serve as reference for your team(s). Such items should be editable by certain persons only, and should only be referenced from other objects.
Houston allows you to set an object as “referential”, which will hide it from users’ home page but will still allow that object to be used in relation with other objects.
For instance, an “Equipment failure” object could be linked with an “Equipments” referential object. This would allow users to browse the equipment list without being able to modify it and without having it cluttering their list of objects.
It also provides admins with a master data set where they can edit a list accessible by many users.
An object can be made a referential on simple request to us for the moment, and soon in full autonomy by administrators.