Evo Weekly — 15 May 2026
Snippet

Legal Team Builds Their Own Intake Workflow

15 May 2026 Bianca Manase use-case WIP

Clip

Summary

Pat Seeley, head of legal, built his own intake-and-triage workflow in Evo with barely any engineering help. The form replaces an Asana process: an MFE captures the request, Databricks pulls Salesforce data (ARR, division, premier status), AI triage routes to legal or finance and writes the next steps, and a Kanban task lands with priority and due date. Moving to production next with proper auth so sales can raise tickets directly.

Screenshots

Transcript

BM
Bianca Manase
24:54 – 31:25

So, John.

Michael Pye 24:56

Thank you.

John Ivatt 25:00

Hello, where's my camera working? That's always a good start. There we go.

So similar to last week, I'll be showing a demo of what some of the people who have done Evo workflow automate enablement have been built or have built. And this is 1 built by Pat Seeley being the head of legal. And of course, I have closed the chat with him where he sent me the recording of what he'd made.

It uses a few different moving pieces, and I'll give you a bit of a summary about it before we click start. So the legal team currently have a form in Asana. That form gets filled out and it gets manually reviewed, triaged, and gets put into a core project for a summary of next steps, things of that nature.

So we decided to try and take it out of Asana and automate it in a way that would work for them. Pat did most of this building himself. He just had one or two questions about Um... some of the nodes and the functionality.

So what we did is we took it out of Asana, built a MFE for the front end for the form, and the tasks go into Access Kanban rather than Asana. So if you saw me asking about tables last week, that's why, because Asana you can have tables that you can publish to, but Kanban didn't at the time. Let's play it from the start.

So this is Pat filling out the MFE that it was built in Evo Builder as a quick action. I know that the thought probably crossing your mind, how does authentication happen? There wasn't any authentication built for this as it was a proof of concept of something that he wanted to work on.

And we're looking at getting this moved to production because he would like for this to sit in platforms like Apex where customers or where salespeople might want to raise a ticket for their opportunities. So where they might have a high priority customer, a high premier customer that has terms and conditions that might be outside of our normal scope. So this is where they would raise a ticket. with the legal team for Pat's team to review and pick up.

As you can see, it started running. It starts with a webhook, it then goes into Databricks to pull more data, such as the ARR, if they're a premier customer, their division, things like that. And the reason why they decided to do this is that sometimes the information that they were getting from people populating the assigned form was wrong.

So for example, rather than the annual recurring revenue, they might put them monthly. So then it gets tiered as a lower priority because the revenue that they've been told isn't necessarily correct and that can cause issues. So once the workflow finishes running, which has got two or three components of, So there's two triaging, one to say if it's a legal or finance issue, and then one to triage the next steps and summarise it.

So, hopefully, we'll show up Kanban in just a second, and I can show you guys the workflow as well. As you can see, it's now created a task in Kanban. Based on that submission, it's got the ARR, the opportunity details, the customer, the division, the triage decision with the reasoning, as well as next steps, auditing the issues with their liability clauses that they had a concern about and things of that nature. as well as a due date priority.

So the plan will be to move this out of pre-prod into production and rebuild the submission so it does have the correct authentication to start the workflow. But this is something that the legal team have built with not loads of help from me and hopefully we'll start to see more and more complex things from teams who aren't the most technical. I'll see if I can pull up the workflow as well, just to walk you through it before I lose it. if I'm still signed into everything.

No, I'm not. Give me one second, guys, and I'll reshare my screen once I'm signed in. Evie.

Fine, this one. So, this is the full flow. I won't take up too much time going over it.

There has also been a case study that's been written up about it in Evo, that I'll link in the chat if you guys do want to review and go over what we've built and why, what steps we took. So, it starts with a webhook, which is... within the MFE. So when the person clicks submit, starts there.

Within the MFE, there is a field for the opportunity URL. Opportunity URL is a unique, has a unique ID for Salesforce within it, which we then use to call Databricks and pull some additional details, which I've mentioned, such as ARR, Premier, Division, things like that. Then if it's legal or finance, we built a legal route.

Finance have agreed for what they would like their route to be, so we'll be building that in when we move this to production. And then we've got different agents reviewing it if it is private or public, because if it's public sector, we pretty much have to agree to their rules, while private sector we can sort of push back and say, actually, we don't agree with this liability cap thing. Things like that, and then clean up the code node and store in Access Kanban.

So, we've moved away from a third-party platform being Asana, and have been able to clean up. reduce the amount of inputs from sales, clean up the data that we're getting via querying it with Databricks. and rather than them taking the task, putting that into a cloud project and getting a response, and getting it directly within the task that's been assigned to them. And that was what I am showing off this week.