We have a variety of processes which share common steps, and in an effort to avoid updating multiple places when one of these steps changes, have built out a system that saves the user’s spot when they navigate away from the primary SOP to one of these common / shared processes (usually in a different App), and then return them to the appropriate place in the original SOP when ready.
In our current solution, we save the users step and app in a table before navigating to one of these common steps, and then set up triggers in our “next” buttons to see if the user needs to jump back to the appropriate step in the primary (original) SOP or if they should continue to the next step in the current app. This requires quite a bit of trigger maintenance and can get complicated quickly, so I’m looking for ideas, either architectural or tactical, to build out a system that supports common steps more easily. We don’t have a ton of content, so a major overhaul is OK if it simplifies things long term.
One smaller item that would help is the ability to go to an app or step by loading the name from a variable or table (instead of selecting from the drop down list). I understand this would require valid and unique names, but would allow us to simplify the logic quite a bit. Instead of saying “if this then go here” over and over, we could just say “go to whatever is saved as the user’s next step”
Hello @SimonHood and welcome to the Tulip Community!!
Great to see that you’re building complex workflows and eager to start optimizing them.
Depending on what information is being displayed on the common steps (and what information you need to collect), you can store the information in a Table Record and load it in a step in the apps where it needs to get used. This would eliminate the need to maintain the triggers and switch apps as you would stay within one app and simply embed the information that is stored in the Table Record.
You might also be interested in checking out the dynamic work instructions library content (support article). This would effectively allow you to create a single step that dynamically loads all information regarding the work content (specific to a product / station combination).
Whether or not you use this exact model is of course up to you, but it might be a good series of applications to use as a reference as you start looking at dynamic work instructions or complex workflows.
Loading table records for the common steps seems like a very workable solution, we’ll give that a go. I worry that dynamic work instructions all on a single step is a little too limiting since we have a variety of inputs / graphical elements which we need to vary throughout the steps. These limitations are somewhat present in the formerly mentioned solution, but easier to work around by copying step layouts and inputs (as long we’re good about avoiding hard coding).
