So during this session, we're gonna be covering the power of iPaaS in modern IT. So we're gonna be taking a look at the current challenges with integrations, some of the limitations with existing tooling, a new modern approach to integrations with the Tray Universal Automation Cloud, some use cases, and then we'll jump into a demo so you can see the platform in action. As a quick introduction, I'm Luke Smith. I'm a senior solutions engineer here at Tray, where I work quite heavily with our customers on the integration and automation requirements and help them ensure that they have a more modern approach to their integration strategies.

So really when we look at integrations currently with the deployability of the cloud and business teams being able to deploy and implement apps, we've seen a real proliferation in the amount of apps that there are. Our industry estimates have it around twenty five percent more apps in the enterprise stack over the past five years, but I think that's quite conservative.

At Tray, we've seen an average now of around thirty apps or databases per department. And that is a huge amount to integrate, and you really can't get there with developers and integration specialists who are in incredibly short supply.

Simply developer heavy tools really aren't the solution.

Integration IT requests are actually going up as well. In some organizations, we've seen a ten times increase or growth in the amount of integration IT requests because really behind every automation initiative that an organization have is integration work. But the integration software that we often use goes way back, like, you know, back in the Windows two thousand days, and it's not just designed for the agility that we need. You can't get there relying on a handful of experts and developer centric UIs or scripts. So, really, there's two choices. Either the integration backlog increases or we have to find another way. And so when we look at where and how the integration demands are changing, we're in an environment where organizations are looking to consolidate with less separate tools and more unified capability.

Traditionally, there was only a handful of integrations, but as we covered just a moment ago, there is an increase in that integration requirement, and that's a lot down to those hyperautomation initiatives.

As well, when we look at the traditional way, a lot of it was developer only, but we're looking at more of moving to what we refer to as fusion teams. So you need all of your talent to work productively together to tackle integration and automation, not just stuck in silos. You also have and wanna make sure that you have a good set of composability.

So the idea is that before, a lot of it was quite rogue and disconnected because there was a rush to automate, but that created a lot of waste and duplication in effort and logic. And so composability means developers can pick up what business teams are building and vice versa, and builders can reuse and share to help form building blocks that they can rely on. We also wanna make sure that there is standardized connectivity that can help insulate from changes like API changes, technology changes, but you wanna have a way in which that's gonna be able to be insulated from those changes.

And then finally, we also wanna make sure that everything is frictionless. Right? You don't wanna have to have a lot of legacy overhead. You know, with automation further being adopted by the front lines, and we'll cover that in a moment.

We don't have to worry about a legacy overhead like infrastructure management and apps that aren't enterprise grade or don't provide modern governance. They just simply won't cut it. And we want that growth to be frictionless on every dimension.

And so when we look at the existing tooling, there are tools out there like citizen development tools that are quick to use but don't necessarily have things like governance and observability, really difficult life cycle management, quite a lack of reusability and role based access control, and scalability can be a challenge as well. And ultimately, they become a dead end if you want to deploy it at scale, you know, say, talking hundreds of integrations.

As well, most iPaaS tools were designed for way back when, so some of them are on twenty year old codes basis for use only by integration specialists. And the builder experience of those is often way too complicated for more of a democratized delivery and often aren't designed for collaborative development. You've also got API management tools, but they're obviously often too heavy weight for most integrations. And in some cases, they have it like a low code UX on top, but that's at the expense of flexibility and limited business logic that can be done, which forces them back to code anyway.

And then finally, you've got RPA tools. Right? UX scripting. And then now they seem attractive at first, but integrations and automation dependent on UX versus APIs just simply aren't robust.

UIs change, and you'll have to change your scripts to accommodate that as well.

And so this change requires a new way of thinking. Right? We wanna have fast, powerful automation, integration, and connectivity experiences. Whether you're a software engineer looking to add integrations to your customer experience app or a technologist in finance looking to integrate order to cash or someone in marketing looking to pull a single report from a marketing automation software.

We wanna be able to enable every team to reuse and collaborate. We also wanna make sure that there's universal capabilities to ensure that that can be done. Right? Your organizations are drowning in separate tools for process automation and data integration to hand grown integrations.

We wanna make sure that there's universal capabilities for every use case. And all of that is great, but if you can't scale, it is worthless.

It's not just about speeds and feeds. It's all about elasticity, governance, security, and scaling with that stack change as well. And so this is where we come in, like, with our Tray Universal Automation Cloud. And the idea here is that we have multiple experiences geared to different teams in the organization, but that still enable them to learn and develop on one platform. Underpinning that is generative AI that helps power every experience across the platform in a way that matters to them, as well as being able to cover multiple use cases in one platform, whether that's process automation, data integration, or connecting to any current and future stack to internal and external integrations.

And then finally, having an enterprise call that provides everything that the company needs to scale as they are going out. So let's start with the experiences, Paulson, and break that down a little bit further. So at the top, you have the different personas that might typically use the tool. Whether you're a developer that's gonna be using Trecode for comprehensive developer APIs for application development, whether you're a technologist that's gonna be using a thing called Trebuild, which is a flexible local builder to integrate and develop integrations quickly and visually, and then finally, TreChat for managers who can execute on the fly integrations on demand using a lateral language, no code automation.

The idea is that everyone can tap into the capabilities in the platform in a way that matters to them, code, low code, or no code. It is truly universal.

And as well, with like other vendors, we are taking a service-based approach with our AI as well called Merlin AI, which is to infuse AI into every experience the way that it makes sense the most.

And so delving into more specifically Tray build, this is the limitless local development portion where you've got the flexibility to incorporate any business logic that you need with our local builder. You've got no code data helpers to help you with those data transformation pieces and the very robust library of connectivity. We have over six hundred connectors on our platform with universal connectors for connecting to other systems as well.

We also wanna make sure that, again, a lot of tools out there traditionally with a low code interface have sacrificed or done low code at the expense of flexibility. But our builder is industry leading in terms of the amount of flexibility that it provides. It's about any process without having to rely on kind of code workarounds effectively. And the builder is designed to give you that capability while still providing it in a visual manner to make that integration velocity much faster.

Delving more specifically into Tray Code, obviously, every app developer build these days has generally got some sort of integration requirement. You know, it's connecting to dozens of services with and beyond the company. And developing API integrations is a rising share in app development, And Tray Code can help massively minimize that. So with something like Connectivity API that leverages our connect capability, you can have programmatic API access to our full library of connectors in just three API calls.

Or you might wanna use an authentication API to simplify authentication management or perhaps developing an event based integration with our trigger API. And so for any developer whose app depends on integration, Tray Code increases their velocity and reduces the overall maintenance with that as well. And then finally, no code. Right?

Engaging purely with chats and no builder required. On demand conversational automations for managers, sales, and customer service. And it's about putting the power to get tasks done that would otherwise require ad hoc integrations or ask into the hands of everyone. We already saw that with how low code massively expanded who can automate and integrate, and this takes that a step further and address the amount of it addressable users that can make use of the tool.

And what's also really cool is that Merlin AI is powering our experiences today. So combining low code development with natural language that you can ask Merlin how and to help you build out a workflow for a particular integration, all the way to Tray Chat, which is that no code natural language approach for frontline people who prefer to integrate in more of a chat capacity. It's infused into those different experiences so that all of those personas and users can make use of it in one single place.

Then we've got the capabilities. So we've seen how we've got the flexibility to automate with our workflows, with code grade logic. We've also got the ability to integrate, and that's things like data storage, data mappers, helpers, and data tables. But also being able to connect in many different ways as well, whether that's to apps or databases with our connector library, whether that's through universal connectors, connect pretty much any rest, SOAP, or GraphQL API, and then also being able to extend on that connect capability with connector building functionality so you can build your own connectors to use on the platform.

And then finally, what we refer to as activate. So that's covering things like what we refer to as our config wizard and a fully rebrandable, customizable self-service activation experience. And so we make it simple for product and IT to roll out integrations that anyone can activate in a few clips. And really those capabilities are universal.

And then finally is our enterprise core. Right? The core is everything companies need to grow with confidence. So that's workspaces, that's security, that's the governance and security piece from role based access control to a simply a compliant platform that's SOC two type two compliant.

Scalability, so things like zero provisioning and having more of a serverless elastic architecture, has given you flexibility whether you're on prem or in the cloud. And it's also providing that composability whether that's with solutions, templates, and snippets that you can reuse and make use of existing assets.

One of the key things there is that serverless architecture. So when we're enabling or scaling automation and integrations, traditionally, you would have had an infrastructure overhead and kind of a headache effectively because you'll have to worry about how much infrastructure needs to be provisioned, and it just becomes a bit of a nightmare to try and predict. And Tray is a little different in that we have a built up on a serverless architecture to spin up compute automatically on demand. So for example, if you have a seasonal demand spike, you don't have to worry about the infrastructure components that go with that. It's all gonna be done for you. And that helps to free up your IT teams further.

Also underpinning all of this is governance and observability at scale as well. And we'll see in the demo, we maintain full logs of all of our execution runs of your integration so you can see the inputs and the outputs. You can stream them out to services like Datadog if you want to do data ingestion.

It also includes things like sandbox and life cycle management, versioning, analytics so you can see how the platform is being used. And this is incredible because it's a super important that when you've got a highly collaborative delivery module, you need to make sure that there's a solid governance and observability underpinning there as well.

And so how does that translate into use cases? Well, there's, you know, a whole host of possibilities here. Here is just a few examples whether you're in IT looking to help with employee onboarding or user provisioning. Perhaps you're looking at customer service and ticketing to improve that side. There's a whole host of areas in which integrations and automations can play a part there as well.

And so that's the Tray Universal Automation Cloud. You can start to see how it is universal across every experience and use case from internal to external.

And so really when it comes down to how this can help businesses, when we look at some of our kind of larger and existing customers, it's helping them improve their low code velocity. Right? The speed to innovation and delivery is critical for organizations in providing them with the velocity that they need. The adoption of low code continues to grow. And so, for example, Cisco was looking to deploy an integration platform to unify their marketing stack. And they rolled out thirty production integrations in four weeks, which was significantly faster than their existing API management platform.

It also helps deliver efficiency, so Airbnb have a ninety percent integration productivity boost. It also helps with collaborative development. So with large enterprises, collaboration is key. When multiple individuals and teams are building, NetApp was able to move to more of a fusion team based delivery model for customer experience integrations. And they rolled out ninety flows across sixty apps with a team of business users and technologist builders across the business. And then finally, there's the elastic scalability. So IBM selected Tray using our elasticity to speed up their data integration process loading PostgreSQL data, speeding up the landing of that data by ninety percent without having to provision or worry about the infrastructure provisioning alongside that as well.

Let's jump into a demo of the platform then. So we'll take a look at two of the experiences, Tray Build, which is the local builder, and then Tray Chat, which is that natural language interface as well. So for this use case, what I've done is I've created a very simple example which allows me to send a Slack slash command with a user's email address to pull back the groups that exist within Okta. So let's take a quick look at what that looks like.

So I have Slack up here, and I've got slash user group. And I can pop in an email address that I want to search for. That will go away, and that's going to search for all of the groups that that user email address is a part of. And you can see it's pulled that back quite nicely.

So this integration that was built using our local builder, and we can see what that workflow looks like just here. So you can see it's very visual. It provides a nice breakdown of the kind of the flow and the structure of the workflow itself. And back to the Tray Build section of the presentation, you notice the three main sections that we covered there.

So you got the core connectors, which is kind of the structure that you're seeing with the boolean conditions and the loops, the helper connectors so you can start to see some of our data transformation and no code helpers, and then the service connectors, of course, all of those third party services that we're interested in connecting with. Now we have a whole host of triggers on the Tray platform, including things like webhook initiated workflows and schedules for more of an event based architecture. But with this one, we've actually got an external app event as our trigger, which in this case is our Slack trigger listening for slash Slack commands.

That will send the request to our Tray workflow, and we then augment that and add that on to send a request to Okta with our Okta connector. And so when we've got our connector built into the platform, you can see that I've got the operations over on the right hand side built in, and I can see all of the ones that I'm able to use, including a raw request operation to hit any endpoints just here that I might not have built in. In this case, I wanna grab the user, and you'll notice that Tray is telling me what I need to provide, which is a user ID. And so I can use our connector snake to actually drag and drop onto the Slack step and say, hey.

Point it to the text that you're getting through from Slack. Tray will also show me the output that it expects to get based on this operation, which is really handy because it gives me an idea of the data structure that we're dealing with. What I've also got then here is per what we call per step error handling. So I've decided to manually branch out.

So if this step happens, I want to branch out and go down the left side if an error occurs or go down the default side if everything's okay. The reason why is that, one, I wanna make sure that I have a robust workflow with this error handling approach. It gives me a lot of flexibility about how I want to respond to errors. But two, Okta will actually return a four zero four error if the user can't be found.

So I've incorporated in here a Boolean conditional check to basically check to see what the response code coming back was from our call to Okta. And so if it's equal to 404, then you'll notice that I'm going to basically go down the true branch and send a Slack message to say that this user has not been found. It's a really nice way in which I can be able to start branching out my logic based on error conditions. However, if all is great, we can go down the default side and we can carry on with our kind of logic.

So we know that the user exists in Okta. That's the first track that we've completed. Now just the way the Okta API works, I can't just send it to that user and say, hey, which groups you are part of. Instead, I need to list the groups and then grab the memberships of those groups and see if my user that's been searched for is part of that.

So the first part is again another call to Okta so we can use the Okta connect to list groups operation, and that will return back an array of results, i.e., an array of the groups. So that makes sense. We wanna be able to loop through that so I can put in I've got a loop step here that I've referenced the results array for. So I'm basically saying, hey.

Loop through each of these groups individually.

Within that loop, we then use another call to Octa basically saying list the group members, and that is another operation here. And you'll notice that Tray is asking for a group ID for this one, which we can easily obtain from the reference of the data coming through on the loop, i.e., the ID of the group.

We then have our first data transformation piece. We're basically using our list helper and an operation called find object in list. I'm basically saying take the output of this call to grab the group members of the group that we're dealing with and see if there is a match for an object structure that's got the profile as the key and then the email address matching the email of the user that we're currently searching for. And that's gonna return back one of two things.

It's either gonna return back null or no information, I. E. There was no match or it will return back the match itself. So I can use this in another boolean condition to basically say, hey.

Take the value out of this, you know, kind of helper connector. If it's not equal to null, then I'll go down the true branch. If not, I'll go down the false branch. False branch, of course, being that the user is not part of that group, so I can skip over that.

But what I wanna do is I wanna build up basically an array of users that or groups that this user is a part of. So in this case, I'm gonna use our data storage component, and I'm basically gonna add on a penta list. So I'm gonna create an array for each group that we come across that the user is a member of, add it on to the end of this array. And that will loop through each of the groups in my Okta instance, checking to see the group membership and seeing if the user is a part of that.

I then grab that membership at the very end. I'm basically saying grab the data storage value, which is great. So I can grab that at the very last point, and then I'm gonna use that in my Slack message that I'm sending. Now I've done this in separate Slack messages.

You could do this in one, but this just helps break out a little bit more. So I'm gonna send the first message to say this user belongs to this one, and you can see I'm starting to interpolate or interpolate information here by referencing, for example, the email from Okta directly within this string that I'm sending. I'm then gonna loop through my groups and then send an individual Slack message, again, referencing information from elsewhere in my workflow with this really helpful connector snake. So it's a really nice visual building experience to build out this logic, and you can see it and follow the flow of this really nicely.

What's really cool though and one of the nice things is that we maintain a full log of all of the integration runs as well. So was it successful? Was everything happy? Did it all go well?

And that will also break down to each and every individual step as well. So I can see the first call to get all of the groups.

I can break down each one of my loops and see which group it was looping through and what happened within there. And this is really powerful when we start hitting error conditions because I can see exactly what went wrong and why it went wrong as well. So this full visibility means I have full visibility of my integration and automation that I can use and be able to have that access to so that I can make debugging easier and just have a really good visibility.

One of my other favorite features is our alerting workflow. So, again, we wanna make sure that our integrations are robust, and we can have an entire Tray workflow run when an error condition occurs. And you can see how flexible a workflow can be. What that means is that the world is your oyster in the workflow that you wanna design for an error handling scenario as well. So some really nice features to help make that building experience both easy as well as being able to have those robust governance controls and observability as well. We also do maintain a full audit log so we can see exactly who made changes to the workflow as well as rollback. Let's finish up then by taking a quick look at that second experience Tray Chat, which is the natural language automation.

So switching over to the Merlin interface, you can see here that I have the ability to type the request in. So let's say I wanna ask Okta for some information on or if I wanted to ask it to basically provide me with a table of information from Okta of the groups that exist within the Okta environment, and I wanna format that into a table. So I'm gonna provide it with that prompt there. I'm basically asking it to take the information.

It will come back in the profile section and just use that as a table name. And you can see Melton is gonna go away and double check to see what it needs to do. So it knows it needs to grab all the groups from Okta. Because we're using Okta, it's gonna ask us for the authentication, so I can hit confirm there.

It's also gonna tell it then tell us the operation it's gonna do. So list all groups on Okta. So the same as what we did in the local builder there, but it's just making sure that we're happy with that and confirming it. And then it's gonna go away and pull back that information for us.

So You can see it's got the first table and then the second table here is a nicely formatted one where we've got the name and the description of the groups that exist within my Okta environment. Now, of course, I could give it extra parameters if I wanted to format this in different ways or pull other information. But hopefully, this gives you a good idea about how you can start using this third interface, Tray Chat for that natural language automation.

So to kind of bring things all back together, that's really kind of what we have here is the Tray Universal Automation Cloud. You know, it's multiple experiences geared to different teams in the organization, but still enable them to learn and develop on one platform. It's underpinning that with generative AI that helps to power every experience in a way that matters to them, and it provides multiple use cases in a single platform. That's from process automation to data integration to connecting to any future stack. And finally, it's providing that enterprise core that everything kind of the company needs to be able to scale as well. Thank you for the time, and any questions, do let us know.