Managing Triggers on Button OR Barcode Scan

Product Suggestions
1

Problem:
Frequently while building Tulip apps, there are steps where an operator can either use an input and a button to move forward, or they can scan a barcode to move forward. In these scenarios, app builders have to be very careful to have the exact same trigger set on both the button and the barcode scan trigger. This is both tedious and extremely error prone. Especially as things grow in complexity and look like this:

image

Solution?:
I know that in the longer term Tulip would love to have more “function” type of triggers which can abstract logic to be used in multiple places. But in the meantime, I wonder if there is a powerful and easy way to mitigate this and potentially unlock further use cases…

If there was a trigger I could put on a button called let’s say “Trigger Barcode Scan”, where I could easily simulate a barcode scan from a button trigger, then this entire nightmare could be streamlined and I bet there would be some other cool ideas for how to use this too.

2

For now you could:

  • trigger a machine api and use that machine output as trigger in the app (quite complex and special solution)

  • have a custom widget, that gets activated by a bool (and only resets the bool value to false)
    The enter, barcode and button trigger then only set the bool to true and the widget activates the actual trigger chain.
    This is also possible with the delay widget, set to 0ms delay.

I guess you know these options, but in case someone likes to try them out, I mentioned them just for showing whats already possible.

3

Yep, those are good ideas. Another trick I have seen is using a “shadow step” which carries all of the logic on step enter and then routes you either back or to the next step.

It’s amazing what is possible but it should be a bit simpler.

2 Likes
4

Hi Daniel, thank you for reaching out and posting.

You’re right - our team is focusing on planning out first steps into Functions right now, so I am hesitant to distract too much from that work for quick wins into this parallel but valuable direction.

Here’s some effort/value questions:

  • how many such button/trigger combos do you estimate you have?
  • how much time do you guess would be saved if you had this magic workaround?
  • what’s the impact of making a mistake here - is this in a workflow that has to be error free 99.99% of the time (e.g. a regulated life sciences case), or is some debugging by App Operators and Admins ok?

We’ll be asking more for this kind of value/effort/impact questions info as we frame and evaluate quick wins against each other, to see what we can inject in parallel to the roadmap.

  • Olga
5
  1. This is extremely common, I build this for almost all app steps which use a barcode scanner because barcode scanners break sometimes or labels get ripped. And my goal is usually to use barcode scanning as much as possible.
  2. The cost here is very little to do with time savings (although my wrist disagrees).
  3. It is the cost of mistakes when app builders do not perfectly sync their triggers. Can cause huge data discrepancies and investigations if not caught. Imagine that a regulated customer adds a trigger to capture the operator name for an action. Their QA process validates it (with only a barcode scanner) and the improvement is deployed. They run for 6 months before someone finally looks at the data and realizes that 10% of product does not have operator information stored for when the manual process was used. Chaos ensues.
6

Gotcha, thanks Daniel.

Part of why I want to look into this is because our first iteration of Functions likely wouldn’t include hardware device calls - device logic would probably be a follow up, once we have an MVP.

I’ll connect with the team to review your suggestions, and see if we have any quick win ideas around device triggers, which are easy to fit in and aligned with our vision for Functions - i.e. which don’t create bad trap door decisions for app builders in the longer term.

I’ll circle back if we can find something in the 3 month range, otherwise let’s check back in at the end of the quarter, as part of Q1/Q2 roadmap planning.

  • Olga
7

@danielpomeranz
In your case I move the logic into the “on step exit” part. When pressing the button or scanning the barcode the step is left and the logic is applied beforehand. If there are several routes the user might take on exit, I use the hidden step as you already suggested.