Build Better: Discover What's New in Tulip (LTS 14) - April 16th @ 11am ET

Announcements
1

Hi Tulip Community -

It’s time for our next Build Better session - What’s New in Tulip (LTS 14) on Wednesday, April 16th from 11am-Noon ET.

Though we will cover the specifics of LTS 14 (@life_sciences :eyes:), all these features are new to Tulip in the last 6 months and anyone is welcome to attend to learn more about the latest enhancements and feature updates.

Discover new capabilities designed to improve app building, integrations, and platform management, especially for regulated environments.

We will cover new features, including demos of how to use them, such as:

  • Conditional table formatting
  • Enhanced vision integrations
  • Automations improvements
  • Machine attribute write
  • App diagrams to visualize logic
    … and more!

Sign up on Tulip University here!

https://university.tulip.co/build-better-sessions/

Let us know if you have any questions ahead of time or any specific things you’d like to discuss in the session by commenting below!

See you there :wave:

3

Reminder that this session is happening tomorrow at 11am ET! It’s not too late to sign-up here: https://university.tulip.co/build-better-sessions/

4

Hello Beth do you have a link for the replay of this session please ?
Thanks

5

Hi Beth
I’m very interest by “Auto Provisionning Station”, I have tested it and it work fine.
On the slide that have been presented, I have understand that the provisioning could be link with Group of user or SAML Attribute. But I didn’t see this feature on my instance. Is it already available or behind a FF?
Thanks

6

Hello Nicolas, are you on at least LTS13.4? That is the one where we automatically enable the “if user is in user group” trigger logic. If not, we can manually enable it on your instances as well.

7

Hi Kevin,
Ok I see this trigger logic.
I thought that we could use the “user group” to define automatically the station group, like in the workspace setting “Auto-provision stations and interfaces” we could define the default “Station Group” by “user group”.
It could be usefull: An operator is link to a group of user in our Active Directory (ie: "Operator - production assembly). At first connection, we could directly create a station under “production assembly” Station Group with the right Apps.

8

Agreed, Nicolas. The reason we hesitated to go further with this behavior is that it would create a big mental model shift, and would split the definition of “who can do what and where?” into too many places. There are many customers that prefer to think through permissions around using the Player spatially as a communication tool- ie “people at this station can only do this sort of thing”.

So until we have a good plan on how to mix the two permissions models at scale, we launched this behavior as a low-risk technical change, but high-risk from the perspective of “will our customers actually be able to use this successfully at scale?”

1 Like