I’m excited to introduce Release 281! This release includes updates to Automations, Analytics, Copilot, and more, plus a few UI improvements across the platform. We’re also rolling out a new feature into beta testing: user groups! We’ll post a separate Community thread soon to introduce this feature where you can also volunteer to participate in testing.
Here are some features in this release worth highlighting:
When executing an automation test run, you can choose between different connector function environments
Added news feed events for automations
New analyses now default to the universal template
Enable data labels for bar charts in the Analytics Editor
See training status in the Copilot widget UI in the App Editor
There are also some performance improvements and bug fixes that were reported by users.
Last thing from me - the User Groups feature in Tulip is now in Beta! User groups allows you to organize users by assigning them to a group. You will be able to reference these groups in different parts and features of the platform.
We are actively recruiting beta participants to help test user groups. Please note this feature is only available for Enterprise level plans and above. If you would like to participate, please let us know by commenting below or by contacting your Customer Success Manager directly!
You have made the following change for Automations, which is challenging me and I need a solution from you:
Now, in machine triggers, repeatedly using the Clear action on a Machine Activity Field will always fire an automation with the corresponding Machine Activity Updated event, even if the field is already cleared. Additionally, repeatedly using the Create Machine State action with the same machine state will always fire an automation with the corresponding Machine Activity Updated event. Previously, repetitions of these actions would not fire additional automations.
Until this change, it was very easy to react with Automations only to machine status changes with Event Type “Machine Activity Changed”, Machine “The machine I want to track” & Machine Activity Field “Machine State”.
I know that I should now try to change the triggers on the corresponding machine type so that the “Create Machine State” action is only executed when changes are made.However, this is not possible with a combination of 5 attributes, so I use a trigger that is triggered by “any Attributes”. However, the machine also outputs an attribute that transmits the PowerOnTime in 10-second increments.
As a result, the automation is unnecessarily triggered at least every 10 seconds and a lot of automation tasks are tracked.
This change makes sense in some cases, but can you at least add an option to the automation that allows you to choose whether you only want to react to machine state changes (like before r281)?
Thank you for sharing - I’m not sure that I understand what the intended effect of this automation is and would like to understand the use case a bit better. Are you triggering the automation off of “Any Attribute”?
To address this more generally, we will be improving event filters to allow automations to fire off of more granular events so this feedback is valuable, and understanding this use case would aid us in how we address this.
no, i trigger the automation at state change of a specific machine:
Before r281 everything was fine, but since your change to “repeatedly using the Create Machine State action with the same machine state will always fire an automation with the corresponding Machine Activity Updated event.” it fires to often.
Inside the machine type trigger of the specific machine im using “Outputs Any Attribute”:
I need to check the combination of 5 Attributes, so I need to use “Any Attribute”, but this is also the reason why the “Create Machine State” Action fired every 10 seconds, even if it is the same state:
A detailed example:
The machine has been in the “Running” state for an hour and then changes to “Stopped”. During this one hour, the trigger of the “Machine Type” with the action “Create Machine State → Running” is executed every 10 seconds, as it reacts to “Outputs Any Attribte” and there is a PowerOnTimer as an attribute that is incremented every 10 seconds.
Previously, the corresponding automation was only triggered in this one “State Change” of the machine from “Running” to “Stopped”.
Now, this automation is also triggered every 10 seconds when the state changes from “Running” to “Running”.
So instead of executing the automation once, it is executed 360 times in this example.
So what I need as a setting in the automation is an option that the automation is only triggered when the machine state really changes (like before r281).
I am quite excited about the User Group feature mentioned in the release and cross my fingers that it makes it to a LTS release really soon! Our projects on LTS flavor in an SAML integrated environment so I trust that this solves our user maintenances issues.
We deploy apps per process area and maintain who is allowed to use the provided apps on user level in a separate table. So we have e.g. “Automation”, “Drug substance”, “Cleaning”, “Finished products” app suites that we manage access to. Some users obviously have access to apps within different groups.
What I wish and hope for is that the AD groups/ SAML can drive this. We have access request systems which ensures people are assigned to AD groups as required. In the AD we can assign users to multiple groups and the SAML response include all. I really hope that Tulip picks up on this and assigns user to all appropriate groups. What we do not want is to have to make “Automation_Drugsubstance”, Automation_Cleaning", “Cleaning_Drugsubstance_Finished products” and maintain all possible combinations.
Thanks for optimizing this time-consuming maintenance tasks!
That makes sense! We don’t plan on changing the behavior back to its previous state but have work planned in the next few months to allow automations to run off of a change in the field, not necessarily posting to the same field.
For now, a workaround could be a decision block that could check for the machine state.
Hi Asger, I am the product manager for the User Groups feature. Would you be willing to do a 30 minute call to tell me more about your AD setup? User Groups will indeed be compatible with SAML, but want to make sure it suits your use case.
all right, I’m looking forward to the further development of the automations. Every new feature opens up new use cases!
Yes, I’m currently trying out a lot of workarounds.
Just as another idea: What could help with many use cases here would be variables that are not cleared with every run. As we know it from Node-Red.
Flow variables that are available within the automation for each run or global variables that are available across all automations.
This saves a lot of complex workarounds using tables.
