I would like to propose a feature for Account Owners / Workspace Owners to notify any message to all users in that instance/Workspace.
I think the upper part of the Splash screen for each Apps can be used for showing the message.
One example is to notify the scheduled maintenance down time of the Connector funciton.
Hi Aoki-san, thank you for this idea. Let me make sure I understand- are you saying that at your company, certain external systems may be down for maintenance. So, you want to add a warning at the top of the Player when this happens, so that users understand that the connector function(s) in their apps may not be successful and therefore they may not be able to send/retrieve the right data?
@danielpomeranz has a very good tutorial on how to do this. https://youtu.be/d6n3CZCRLlA?si=OSxzkZ2vpSZ7YL7f
Dear Kevin-san,
Yes, kind of.
I want Account Owners to have a way to announce something to all Tulip users.
Connector downtime is just one example. It could also be a scheduled maintenance announcement of the Tulip instance itself. (The user would not see the message when Tulip is down, but we could announce that several days before the schedule)
It could be a way to guide our users to internal FAQ site.
Thank you for the information!
In our instance’s case, we have so many Apps already. Adding the message showing widget to all the Apps are unrealistic.
Understood! Will track this alongside the project that we call “Notification Feed” internally.
As for scheduled maintenance events, we are launching a support article in April that will share this schedule for every instance. So look out for that announcement soon!
It would be also great if the Account Owners / Workspace Owners could customize those red notification message show in the splash screen. I want the message to be customizable depending on each specific Apps .
One example I have in mind is that when we have to stop support for specific Connector Functions (e.g. due to switching DB/ERP system).
If that function is used in many Apps developed by many citizen developers, Account Owners / Workspace Owners would want to show the message “The Connector Function ABC used in this App will be not supported after 202X-XX. Please revise the App” on the splash screen to warn the users/developers.
( @k.ober this is the idea I was talking about in the APAC Office Hours today.)
Add a feature that displays a banner message across the top of Tulip Player for selected operators, user groups, stations, and/or station groups. The banner will appear regardless of which app the targeted user or station is running and will remain visible until manually dismissed, similar to the banner notifications in the Tulip App Editor. This would be configurable as a workspace setting and could be completed through a trigger or automation.
Current State:
Currently, we rely on tables and table updates to communicate major changes or notify users of updates. However, this approach depends on users actively checking the tables, which is not effective for urgent or time-sensitive information. Additionally, operators do not have easy access to email, Teams, or Slack, so Tulip is their only formal method of electronic communication.
Use Cases:
Mass communication (e.g., urgent announcements)
Notifying users of completed help tickets
Sharing updates, maintenance alerts, or instructions
Highlighting errors, process changes, or training tips
Bottom Line:
Ensures important messages reach all relevant users and supports clear, consistent communication across operations.
A notification/popup/banner option would be a great addition to daily operation. Especially if it can have the granularity for station or user groups.
We had similar use cases where we want certain users to get real time notification when access to other communication channels is limited.
As a work around for this use case, we used timed trigger and reference tables that controls the notification and routing for each station. The timed trigger is an ad hoc solution to mimic a somewhat just-in-time notification, where it would check for an update and direct user to a notification page. The content displayed on that page is linked to a record on that station/notification table. It sounds like you already have similar tables for that.
Being cautious on compute and performance, we did not implement this as an app level trigger but focused on only key steps. With that, we haven’t observed any noticeable performance impact.
It is definitely not elegant being something that relies on a timed trigger, and group management is clunky. But it could be something to consider until Tulip comes up with an official function for this.
I think an example like this one with machine triggers and using the snackbar widget could you pretty close to what you want. Or at least an improvement over the current manual check for messages.
@adeveloper, thanks for your suggestions/thoughts, and @jjj, thanks for sharing the machine triggers video-I hadn’t seen that before! I’ve also considered building a more robust notification solution or using a custom widget. However, our main limitation is the scale: we have around 500 applications that our operators may be using. Adding a custom widget or reference tables into all 500+ applications isn’t straightforward and would require significant effort to maintain consistency and reliability.
That’s why we’re hoping for a native feature within Tulip that can deliver targeted notifications or banners across all apps, without the need for manual implementation in each one.
Problem / Context
Today, operators are not informed in advance when Tulip maintenance or release activities are executed. This lack of visibility can lead to unexpected interruptions during critical operations and increases the risk of data corruption or incomplete transactions.
Short-term / Temporary Solution (Workaround)
As a temporary mitigation, we plan to implement a declarative maintenance mechanism:
Create a dedicated Maintenance Events table to store upcoming maintenance windows.
Run an automation that:
analyzes upcoming maintenance events,
updates a machine attribute with a maintenance notification message.
In Tulip apps:
the machine visual status will change color 15 minutes before maintenance execution (Maintenance mode),
once the maintenance end date is reached, the visual state returns to the normal color.
This approach will:
inform operators in advance,
allow them to postpone critical activities if needed,
significantly reduce the risk of data corruption caused by maintenance interruptions.
Current Limitation of This Approach
This solution remains fully declarative and does not rely on real-time feedback from Tulip.
There is no reliable confirmation that maintenance has actually started or completed, which limits robustness and trust in the notification.
To address this gap, we suggest the following native capabilities:
Expose scheduled maintenance and release events in a system table (or equivalent), automatically updated by Tulip.
Provide a real confirmation signal when:
maintenance starts,
maintenance is completed (e.g. via a system table update, app info flag, or event trigger).
This would enable:
reliable pre-maintenance notifications (e.g. 15 minutes before execution),
accurate end-of-maintenance confirmation,
safer operations and improved data integrity during platform maintenance.
Hello Thomas, quick followup question. As you can imagine, the 15 minute window may vary by customer- I imagine everyone would like a warning, but the timing around that warning will vary by individual customer needs.
Does every Player truly need a notification? Or would it be sufficient to notify a production supervisor with similar information, and allow them to make an announcement to all of production at the time that they see fit?
Hello,
From our perspective, all users should be notified, not only supervisors.
The key reason is transparency and autonomy at the operator level. Operators are the ones executing critical actions in real time (data entry, confirmations, validations), and advance visibility allows them to organize or pause sensitive activities accordingly, reducing the risk of partial transactions or data corruption.
We also fully agree that supervisors should receive notifications as well, potentially with enhanced visibility or earlier alerts, so they can coordinate and support production as needed.
Regarding the 15-minute window, we see this as a configurable parameter rather than a fixed requirement. Different customers and processes may indeed require different lead times, and flexibility here would be important.
In summary:
Notify all active users (Players) to ensure transparency and safe operations
Notify supervisors as well, possibly with extended context or timing
Make the warning window configurable at the customer or site level
This combination would provide both operational safety and flexibility across different use cases.
Best regards,
Thomas
Thank you! I am merging into another similar thread to consolidate voice of customer.
