I am trying to implement a “report incident” function that will be used for multiple (almost all our apps). As shown in the different templates, I can create a button that will link to a specific step “Report an incident”. That step and button could be copy/pasted in all our apps.
However, it seems against best practice to perform like this (the workload of updating the “report an incident” step will be multiplied by the number of implementation).
A better option would be to create a dedicated App for Incident Reporting.
In this case, when the user wants to report an incident, the “main” app will need to be either completed or cancelled in order to launch the Incident Reporting app.
Is there a way to embed such a small “report incident” app within the main app?
It may become a feature request.
Actually your first approach is the Tulip best practice recommendation! Tulip is designed to be “composable” meaning that you can make all these small building blocks in steps or apps and use them in many places and in many different solutions (read more here: Composable vs Monolithic Architectures). I can understand the thought of wanting to have only 1 incident reporting app, but this can actually get complicated down the line as you scale and have more and more process and apps all routing to one reporting app. We encourage thinking from the human centric approach about what makes most sense for your operators and for others looking at apps in the future to be able to replicate them.
That being said, we are going to have some focused office hours coming up (stay tuned, I will post on Community about it) about building composable solutions and our common data model that allow all of this to happen and show you how to best put this advice in to action.
I really like the “composable” approach of building little bricks and being able to use them in other apps. What I do not understand is your need to replicate everything.
If I create a single “reporting incident” app (building block) that is created in collaboration with multiple operators and in alignment with my “incident report” SOP, why would I need to copy paste it in all other new projects?
Why is it against your best practice to centralize key functions into single apps/blocks that can be used later in other projects (without the need to copy paste)?
How could we scale a project if every instructions/apps must be tailored made for each workstation?
How could we implement Data governance, App governance and always apply the latest best practice in Data integrity with hundreds of Apps built by different persons?
Thanks for the tutorial of Daniel, it is the workaround I was thinking about but it is just a workaround. I would still recommend to post this as Product Suggestion.
As @Sebme recommended in the comment flow of Daniel’s tutorial
I am sure that a lot of your customers would be interested by this feature.
What you are asking for is called componentization. At the moment the way to achieve this in Tulip is as @Beth suggested but we are working on additional ways to enhance the required reusability of content in Tulip. Automation is one such way where common logic flows can be used by multiple apps. Another component structure in Tulip is Custom Widgets. We are also working on something we called “Step Templates” that will add to this reuse and probably more directly address the gap that you mention. The need for componentization and reuse has not gone lost on us and I believe you will find some related product suggestions have already been entered, but please add this one as well.
While the gaps that you bring up are valid we find that it is still doable to manage apps even at the scale of 100s of apps in this manner. We recommend maintaining an “App Manifest” that can be used to make sure that any changes that are needed to be done to multiple apps are logged and tracked. This is simply a list of all the apps in a solution with their versions and dependencies. And yes we are also considering bringing the App Manifest as additional features to the platform.
Thanks for your answer.
Custom widget would indeed fill my gap, but at the expense of great validation effort (pharma industry is not kind to customized elements).
While Step templates are a good idea, I’m still strongly against hundred of copy/paste of the same step/code, even with “Step Templates”.
I will raise a feature suggestion for a componentization feature that is not too heavy.
Hi @kefl - I see a few options have been shared in the is thread, but as discussed, all are limited in different ways. Our goal is to strike the right balance so you don’t have to repeat yourself and we have a big focus on that this year. Would you be interested in talking more about it? I’m especially interested in how you are approaching validation of the apps/components. If so, you can schedule a meeting here. If not, no worries!