Hi! I am an enterprise customer and do not have access to the “Cancel Tulip App when Player is closed” feature flag. I understand this is a feature for regulated industries.
I’m submitting a product suggestion to grant enterprise customers access to a similar feature flag. Specifically, I’m referring to the functionality where when a user clicks the red X button in the corner of their player, the app cancels in the context of Tulip app completions. This addition would greatly enhance our operational efficiency and compliance measures.
I second this, allowing an app to continue running in the background while the player is closed creates several issues for our use case.
2 Likes
It’s a bit janky, but I actually think we have a more flexible solution. You can configure this on any app by using this custom widget setup to fire a logout trigger whenever the Tulip Player is re-opened. Its effectively the same outcome.
Hi @danielpomeranz thanks for chiming in! The solution you shared focuses on when a user “signs in or when someone re-opens the player.” However, our concern is that many of our apps continue collecting time data in the background, even when the app is physically closed. This means data collection is ongoing, even if users aren’t actively interacting with the app. So unfortunately that solution doesn’t fix our problem
1 Like
Yep, that is one of the scenarios where this definitely won’t work.
What if you saved the most recent timestamp every 30 seconds via timer trigger? Then backlogged a time correction since you will roughly know when the player was closed? You could probably even solve this in the background with an automation which parses a station table with a “Most Recent Activity” field.
Hi @nicolettenaya, @henry.hover, & @danielpomeranz,
We are planning to enable this for customers over the next few months as an account setting.
Sincerely,
Jake
3 Likes
@jakerigos Please also consider adding this as an App or Step level trigger event instead of an account wide checkbox. Flexibility is usually better.
1 Like
Hi @danielpomeranz,
That’s a great call. However, it’s also another magnitude to two plus of work. Currently, this feature is implemented as an account-wide setting and that flexibility would require a lot to get done.
Sincerely,
Jake
Awesome new, thanks Jake!
Yahoo! Great news. @jakerigos to confirm if we configure this new feature once we have r323 when the player is closed the app will cancel and all “App Cancelled” triggers will run on the open app before the window is closed?
1 Like
@nicolettenaya, The app doesn’t cancel when player is closed. It happens when the next time player opens up, the app runtime detects that the last activity time was quite some time ago and figures out that player was closed in the mean time and triggers the app cancellation.
1 Like
@jakerigos I see — thanks for clarifying. A core part of this request was for the cancellation trigger to fire when the app is actually closed. If the triggers don’t fire until the next time the app is opened, the specific actions tied to cancellation won’t execute within the correct time frame. As you mentioned, if it’s triggered after “quite some time,” that causes issues for the data that should be sent or saved at the moment the app is closed.
For example we have triggers that interact with our ERP — when an app is canceled, the order is marked as paused via API. If the cancellation trigger only happens the next time the app is opened, the order will be paused with an incorrect timestamp, which creates confusion and data integrity issues.
1 Like
Hi @nicolettenaya, I understand how this behavior would not solve the problem and how that behavior is confusing.
@jakerigos The term “Cancel” is misleading. Should I submit another product suggestion to make this part of the feature? or an this product suggestion be opened back up?
@nicolettenaya, I would open up another product suggestion. The core of this request is please add “cancel app on operator logout” as a account setting not change the core behavior of “on app cancel”
@nicolettenaya, to give you a bit more rationale into why this isn’t feasible:
- When the Tulip Player client is closed (Xed out, power outage, etc.), it can’t do anything and we can’t rely on it being Xed out because a power outage would also count as a Player being closed.
- On the server side, we notice that it has disconnected but we don’t know why it has disconnected it can be one of many things, like an Internet outage, etc). Then, we save that logic for when the operator logs in again.
However, this is something that we can look to eventually tackle as a separate suggestion. I know this doesn’t solve your problem but I hope it lends some insight into why this happens.