Product Suggestion: Query Parameters in “Open App in Player” URLs

Product Suggestions
, ,
1

We often launch Tulip apps from external shop floor systems that already know contextual data such as the production order ID. Today, operators must enter this information again after opening the app, creating unnecessary effort and potential for input errors.

Feature request: Allow query parameters in “Open App in Player” URLs and make them accessible within the app.

Example:

https://my-instance.tulip.co/open-player?tulip-player=xyz123&productionOrder=123456

Possible approaches:

  • Add a variable setting such as “Allow value from query parameter” to automatically populate app variables.
  • Allow triggers to access query parameters directly, e.g. @query.productionOrder > into variable > productionOrder

(Second approach preferred)

Benefits:

  • Eliminates redundant data entry
  • Improves operator experience
  • Reduces input errors
  • Enables smoother integration with MES, ERP, and other shop floor systems

This capability has already been discussed multiple times in the Tulip Community and would greatly improve interoperability with external systems.

E.g. already mentioned here:

Open Tulip App with URL including parameter - General - Tulip Community

QR codes to open step and pass parameters in code link - General - Tulip Community

2

Thanks @thorsten.langner! We are tracking this request internally.

Two patterns cover most cases in the meantime:

  • Pull from the source system. When the app’s first step opens, a connector function asks the MES or ERP for the current order at that station and stores the result in variables (run a connector function in a trigger).
  • Push through a Tulip Table. The external system writes the values to a Tulip Table through the Tables API before opening the link, and the app loads that record when the first step opens (Tables API, using tables in apps).

Best,

Ilana

3

Hi @Ilana ,
thank you for your reply.

The stations I am referring to are user-specific tablets. They are not permanently assigned to a particular work center, machine, or work order.

In this scenario, the ERP/MES has no reliable way of determining the current context based on the Tulip station name. In fact, the station name is only known within Tulip. Therefore, I do not see how the source system could infer which work order or dataset should be loaded when the app starts.

If I understand correctly, this workaround would require the non-Tulip system to actively provide the context to Tulip before opening the app.

However, this raises a few challenges:

  • How would the third-party system know which Tulip station should receive the data?
  • The calling application is intended to provide a simple link for the user to click. It is not designed to execute backend logic, perform API calls, or manage application state.
  • Where would the required credentials be stored securely? Exposing API credentials to end users is not an option.
  • Implementing this approach would effectively require building and operating an additional backend service for authentication, API communication, and context management. (Also not an option)

Compared to that, supporting URL query parameters would provide a much simpler and more lightweight solution for this use case. The calling system could simply pass the required context directly when opening the app, without requiring additional infrastructure or custom integration logic.

4

Thanks @thorsten.langner, that’s helpful context. With user-specific tablets and a calling system that can only open a link, neither pattern fits, and building a backend service just to pass an order ID isn’t reasonable. That’s the gap this request covers, and these details are going into the internal ticket.