Stop flying blind: How Truckstop brought clarity to a complex org

Share with

Description

Watch this 30-minute webinar to discover how Gearset Org Intelligence helped Truckstop quickly understand complex orgs, investigate dependencies, and assess change impact without relying on outdated documentation, manual exploration of spreadsheets and schema builder, or a single point of failure. In this session, you’ll learn firsthand from Truckstop how they:

  • Get their teams up to speed on unfamiliar areas of their org in minutes, not days
  • Reduce single points of failure by making org knowledge accessible across the whole team
  • Move faster with less risk by replacing manual org exploration with a living source of truth
  • Quickly and instantly understand the impact of their changes by exploring dependencies across metadata, automation, and permissions

Learn more:

Transcript

Alright. Hi, everyone. Thank you so much for joining our webinar today. I hope everyone's doing well. I'm just gonna give it twenty, thirty seconds or so just before I dive straight in. But thank you everyone for joining.

We have quite a lot to cover today. So, yeah, I won't leave it too much longer.

Alright. I can see we've got quite a good audience with us already actually. Actually. So let's get started then. So thank you everyone for joining our webinar today. Today, we're gonna be exploring how you can stop flying blind when making changes in your Salesforce org. And in particular, how Truckstop brought clarity to their complex org using Gearset's org intelligence.

My name is Nicole Loney, and I'm one of the senior product marketing managers here at Gearset.

And I have the privilege of being your host today. I'm also really excited to introduce our guest speaker, Mindy from Truckstop. She is the Salesforce product and platform leader at Truckstop and brings over, eight years, I think you said it was, experience in the Salesforce ecosystem, and has worked across a wide range of different roles, including admin, project manager, product manager, and architect. So, yeah, a whole wealth of experience here with us today.

In the background, you'll also see we've got, John Dilly and Liz Dubas on the call. They're in our product team looking after org intelligence here at GearSat. So if you've got any questions as we go, whether they're technical about the product or even for Mindy, please do drop them in the chat and we'll make sure we get some time at the end, to cover them all.

You'll probably find John and Liz answering away in the background as we go.

In terms then of format, so most of our call today will, of course, be chatting with Mindy.

But I'm just gonna get us started by briefly setting the scene on org intelligence, covering a little bit of information about what it is, why we built it, and what it looks like in practice. And then we'll dive into the main part of the session, which is our conversation with Mindy. And we'll, yeah, ensure, as I said, we'll save some time for q and a. And it's worth highlighting our session is recorded. So if anyone needs to drop at any time, it's not a problem. We'll send out the recording after the webinar.

Okay. So I just wanna start then by sharing a little bit of information as promised. So at Gearset, as you probably know, our mission really is to give every Salesforce team everything they need to manage the entire DevOps life cycle all from one platform. And on your screen, you can see what the life cycle looks like. It's probably an image you've seen before.

And this life cycle covers everything from planning and building through to validating, releasing, operating, and observing. And as you know, we probably as you probably know, we also offer a wide range of products as well to support each of those stages, like compare and deploy, site CICD pipelines, backup and restore, and more.

Now across the platform, we've been integrating AI where we believe it adds genuine value. And one area where we've seen it make a real difference is in the plan and build stages.

This is where, as you know, you're in taking requests taking requests from around the business and figuring out what needs to change and how to deliver it on the platform. And as we all know, that's rarely as straightforward as it sounds or even as it should be.

Orgs, they get built over time by different teams. People leave. It can be hard to understand.

Documentation, if it exists at all, can be outdated. Parts of it can be missing entirely sometimes, and hidden dependencies, you know, can make changes feel quite risky. And then everything that goes wrong, of course, causes delays and downtime.

And this is exactly the problem org intelligence was built to solve.

And by combining AI with, you know, a a deep understanding of your live org, it helps teams to make faster, more informed decisions about what they need to change and why.

So in reality, org intelligence gives you a complete three sixty degree view of your org. It can really help you to find blind spots, so that you can, yeah, understand the impact of your changes before they cause problems.

And what makes it really powerful is that you can work with it how you want to. And what I mean by that is it combines two elements. One part of it is a visual point and click experience so that you can, you know, explore your org and all the dependencies visually. But if you want deeper insights, you can also opt to use the built in AI agent so you can ask it questions in natural language.

So, yeah, you don't have to use the AI to get value out of org intelligence, but it's there for those that want it and it's really, really super powerful.

And the best part about it is it is really built on your live Salesforce data. So it's also always up to date and you don't have to worry about spreadsheets or, yeah, tribal knowledge or anything like that. And it's also purpose built for Salesforce.

And, yeah, it's not a solution that's been adapted to it. It's been purely designed for Salesforce.

So I'd like to quickly share a short ninety second clip so you can see org intelligence in action. And, Mindy, as I was resharing my screen earlier, I realized I'm not sure if I ticked sound for this. So let me know with a thumbs up if you can hear it. If not, I'll, have to stop and reshare. But here we go.

A new work item has just landed on my plate to build a new process for industry changes.

Before I make any changes, I need to understand what already exists in my org that relates to the account industry change process.

Here's where Gearset's org intelligence comes in. I can simply ask what happens when an account industry changes.

Now this will scan across my entire org and help me understand how this process takes place. And without this, I'd have to spend a heap of time understanding my org using a variety of tooling. So here we see that when the account industry change is triggered, there's a flow that handles this process. By selecting the flow, I instantly see any of its dependencies and references, of course, to understand before modifying the flow. And I can take this one step further to get a visual summary, which helps me contextualize this.

But perhaps I'm still not exactly sure what this flow is doing. I can simply generate a summary to explain the item. This explanation provides me all of the context I need before I jump into action to implement the discounting process.

To support me implement, I can even go back to Jira, copy in my acceptance criteria, and simply ask it how I should safely implement these required changes.

This is where there's immense power of combining deep org awareness with Gearset's expert understanding of Salesforce metadata. I can now go ahead with confidence to build and implement these changes safe in the knowledge I'm not gonna be impacting any process unexpectedly.

Great. There you have it. And hopefully, that gives you sort of a very, very quick overview. I appreciate that on just how easy it is to sort of navigate org intelligence and what the UI looks like.

There are many different things you can use org intelligence for. I'll breeze through them because we're gonna cover them in more detail with Mindy. But org intelligence really can give you some instant visibility into your org. As you saw, it can help you to generate AI summaries of what each item does and why it exists.

With it, you can also perform impact analysis, understand how everything connects together, map dependencies, and, you know, also see downstream effects before they, before your teams make changes.

It can help with permissions debugging, which is a brand new capability that shows you exactly who has access to what and why.

It helps you to automate, or automatically generate documentation, which we've already covered can be quite a struggle to, keep on top of.

And finally, it can also be a great powerful tool for all cleanup. With everything in one place, you can more easily consolidate and simplify your org at scale. So, yes. Anyway, enough from me. I will now stop sharing my screen, and I'd love to, welcome Mindy to the stage. Thank you for joining us today. I appreciate you spending the time with us.

So, I guess, to start off with, it would be great if you could, share a little bit about yourself and your role at Truckstop.

Of course. So I took over the self engineering team at Truckstop, in two thousand twenty five, And my role really sit in the intersection between engineering leadership, technical architectures, and product strategy. I lead the technical architecture and solution design file of Salesforce ecosystem while also aligning our road map to a broader product visions and our business goals. On the execution side, I ensure the project are delivered on time, and was meeting the business need.

But beyond delivery, my focus is on building a more scalable system, redoing technical debt, improve our governance, and make sure our architecture can support where the company is going. I am also responsible for evaluating tool and processes that help the team operate more efficiently. Ultimately, I think my role is about balancing the between the speed, the safety, and the long term act architectural health of the org.

Wow. That sounds like you're balancing a lot.

Oh, that's great, though. Thank you for the context. So given all that then, can you briefly explain sort of the complexity of your Salesforce environment that you're operating in?

Let's Sure. We have all this and so let me try to summarize it quick. So at Kickstoff, Salesforce isn't just a CIM. It's really our operational engine.

So we run CPQ revenue cloud for a very complex subscription model, amendment evergreen, term scale, you name it. We also use b to b commerce cloud for customer sales sign up and checkout. We manage, entitlement, provisioning trigger, and billing logic. All of that connect to downstream system and microservices.

So when we make a small change, instead of what it is really isolated. A single few update can impact coding, revenue schedule, in time and and integration. So everything is interconnected. Our hours have evolved so over many years with different architect, consulting partner, and growth business.

Some areas, I would say, more mature and structure, but other were built quite quickly to support the rapid business expansion. Right? So about seven percent of our logic lives in APAC code right now. So that mean we are navigating custom code, layer automation, legacy trigger, and historical implementations, not all of which are fully documented or easy to trace back to their original intent.

It is a powerful and scalable core org, but it's it's not simple.

So for an environment like ours, the visibility, it has become foundational for us.

Yeah. Yeah. I'm not surprised. It it sounds like it's quite complex set up. And I'd imagine, as you were saying, in an environment like that, even the smallest change becomes quite a complex process. So what did that look like in reality before you had org intelligence?

What would you say were some of the biggest challenges that your team were facing when they were making changes?

Yeah. Definitely. So before org intelligence, I would say the bigger challenge wasn't that we couldn't solve the problems. I we we have a very talented team.

It was how long it took for us to confidently understand the impact of the change. So in a heavily customized code driven environment like ours, even a small chain would have a a wide ripple effect. Right? So when someone asked me, what if happen what happened if I change this field?

The honest answer for me was often, well, it depends. So understand the impact that require manual detective work. We would straight few reference, review flow, so through APAC classes, examine the trigger, and then look to all the integration point, then manually colorate them back together, everything. Because all have evolved over the year with a different implementation approach, not everything was also follow consistent best practices.

So some automation was gonna overlap, some logic live in multiple places. So scope analysis for a medium side chain sometimes take us week to put research. And even with that effort, I had found hidden dependency sometimes separately into the QA phase.

So there was also this knowledge concentration.

Some error I deeply understood by only one or two lead engineer, we create a bottleneck and we said we can't move forward until we spoke to him. So that was an issue of of capability. Right? And the the issue was more about visibility for us.

Yeah. That sounds like it could be it would have been super frustrating actually for everyone.

And as you said, if your team are actually spending weeks unpicking dependencies and untangling everything before they can start building, I bet that pain then doesn't just stay contained within your team.

How would you say that kind of rippled out the wider business and the stakeholders that you were supporting?

Yeah. Definitely. The the product manager and leader, I I I see it firsthand.

So I would say the very real impact on both executions and on the stakeholder confidence. So the bug fixes and enhancement often took long much longer than I expected. That's because we had to spend so much time just to validating the impact.

And so the team were investing significant energy to to grow the research researching, untangling the call rather than delivering and building some new thing. We call it pulling on the spaghetti plate. So I can give you an example that really stood out for me was our b to b commerce site last year. So we needed to understand how we're fully built, and it was painfully slow, and we have a lot of friction for giving our customer sign up, and we couldn't figure out how to to move forward.

We've tried to figure out whether it was an order based or whether it was added user base, what architecture pattern would yield, what dependency that would assist it. And that spike is stressful, close to a full quarter and multiple developer look into it, But because the layer of the customizations and the minimal documentation that we had, we couldn't confidently articulate how the site was structured and what modernization path it it should be. So be honest, from a stakeholder perspective, that looked like the engineering in this season or, you know, we couldn't figure it out. But internally, it was a a deep research without reliable metal terrain, which is kind of the price are pulling on the the spaghetti, and we couldn't figure it out.

And that kind of uncertainty definitely affected my roadmap planning prioritization, but mostly trust from the stakeholder to us. And, the frustration for me wasn't about the complexity, to be honest, but it was uncertainty of how we can move forward.

Yeah. I can I can tell that's really not ideal? And I imagine at some point then, you probably got to the point where you looked at all of that and just thought, well, that's just not sustainable anymore. So, yeah, what would you say then was the tipping point that kind of made you start looking for a new approach? Did something happen or was it just a a realization, if you like?

Yeah. Definitely. So the the the decision didn't really happen overnight that you mentioned.

For about a year, I watched the team spend significant time on analysis before building. And at a certain maturity level, right, detect the work it's a feel like detective works. Start to slow down innovations.

We need something that could augment the team, not to replace the thinking, but more to accelerate it. Right? So we start to evaluate several AI driven tool. You know, I myself use of ChatTV for a bit. It was fantastic for brainstorming solution, But what we needed was something grounded in our actual words, something that understand our metadata, our APAC code, and our real dependency, and that was stood out for me about our intelligence.

So it's analyzed, and I think you you already shared it on your demo. Right? It's analyzed the word on it's just today. It's so but all the relationship across the metadata and code automatically, and it would truly uploads plug and play, which made adoption so much easy easier.

And for me, it wasn't buying a u another AI tool for the team, but it put it was about more giving the visibility to the team that can move faster with the confidence that they we need. And yeah. So that's when we reach out to ViewSet and have the the or turn on.

Great. And when you were weighing up your options then, what was your nonnegotiables?

What criteria would you say mattered most to you when you were going through that process?

Yeah. Definitely. I think I kinda mentioned it a little bit earlier, but I was very clear about what problem we were trying to solve. You know, there's a lot of AI tool out there.

For me, first and more importantly, it have to understand our actual work, especially in a seventy percent code based environment, and it's it's separate and a little bit unique. Right? Second, it need to review the blind spot in real time dependency visibility. Right?

I don't want something, you know, that a long time ago, I want something live that, you know, that you can sit right on top of the org. Third, adoption matter. Right? I know that I'm introducing a new tool to my team.

There's so many AI option out there. Right? I don't want a a heavy platform that require a month of implementation or training. It had to be intuitive and usable across roles.

So to be honest, for work intelligent, we our BA use it, our QA everybody in our team use use the tool.

Cost was also important to us based on our budget. So I evaluate of its productivity investment.

If scope analysis take me, the engineering team have opted cost. Right? So the need to be very clear for leaderships for us to to be able to get the tool.

And for me, finally, one thing I do wanna mention is how to augment human judgment, not to replace it. Right? Our our team is very capable and we just want something to support them and auto intelligent. They might check all the boxes.

Yeah. That's great to hear. And I think quite a few of those points would probably yeah. I think quite a few of those points would probably be relevant for everyone on the call when they're looking for new solutions as well.

So yeah. Great to hear. So once you made the decision to go with Org Intelligence then, how did the rollout actually go? When did you start seeing real value from it, would you say?

Yeah. So I think the setup would truly plug and play. I really told my AE, and you turn it on, and I connect the order, that was it. The interface is very intuitive.

So after really once I mean, I played through it myself first and and use it and understand it first, and then I do a one structure walk through with my team. So the team will come to me using it right away. I would say adoption happened quite quickly. It became part of our daily workflow, unit analysis, and impact review.

We started seeing value almost immediately. Our engineer can understand the core relationship in a matter of minute instead of hours.

Within the first few few months, I would say, estimate productivity improve about roughly forty percent, not because the people are working longer. It's just because they spent so much less time researching and more time building. I like, once in a while, I can give a user story. It might be you can just go in and plug in the field and understand all the impact where before you can be able to do that, And he can turn the user story out just like that and understand, you know, all the use case for it.

That's incredible.

Yeah. Really nice to hear. And is there an example that you could potentially walk us through of how you've used dog intelligence, you know, just to make it a little bit more tangible for everyone listening?

Yeah. Definitely. We use it every day when, you know, I I there's a lot of of a good example. But let me so I think one of the strong example that for us was provisioning and security project redesign. So let me set a little context. So at Truckstop, provisioning isn't just a stand alone functions.

We deeply it deeply tied to CPQ contracts, subscription, entitlement, customer APAC, and multiple integration into our microservices. So it what it does, it drive user assets and can do compliant check and downstream provisioning into the external system. So the impact service is why. It's really big.

And the reality was there was no clean documentation explain how it all fit together. Over the years, the automation have evolved by a bit. The logic had been layered in different phase, and some piece were declarative. A large portion live in APAC.

And there's also a lot of edge cases that view in different time for different business need. So when I step in to lead the redesign, the the first question I had wasn't how do we build the future state? But it more like, do we really fully understand the current state? So before Art Intelligence, that would have required me manual tracing classes and review field reference, mapping flow by one, one by one, and hoping I didn't miss anything that hidden in the code.

And I will be very important present. I'm not a developer. So I can look at those code, and I won't understand any of it. So that was quite a challenge.

With auto intelligent, I was able to separate all the dependency much faster. I can just have it as I can just have the a list of the APAC. I can explain what the APAC is doing. And through that process, I discover a lot of legacy flow that wrapped in the field that we assume they no longer use.

I we identify a lot of the effect plus time to provision logic that wasn't obvious from the setup alone. We can also see the how the metadata and the quote were actually connected.

So that visibly really change the nature of our architectural conversation. So instead of making assumptions on what will be safely refactor or remove, we grounded our whole decision into the actual dependency data. So we we did able to design the new design very intentionally, not more reactively.

So I'd like to say, it won't replay to our actual thinking, but it's accelerated. Right? It's really helped reduce the blind spot.

And for a project I complete, that clearly were very critical for me.

Yeah. That's a great example, and it really helps as well to kind of show the power of the tool for your team. And that makes me wonder if it's having that type of impact on your experienced team members. What about someone completely new? Have you had any sort of new starters recently that you've been able to onboard with the tool potentially? Or yeah. How has it helped in those sorts of situations?

Yeah. Definitely. So it's probably one of the more meaningful shift for us.

We had a new developer who joined recently, and she started using our intelligence on day one.

So in the past, onboarding into a quote heavy, highly customized org like OWL feel very overwhelming because this is you know, I have done that in the the last year with my other developer. It's just there's a steep learning curve because you're not just learning the business. You under to understand, but you also have to understand year of architectural layering. And instead of waiting weeks to build contact, relying on entirely shadowing, sharing, she could immediately explore how the object flow in APAC were connected. So in a short time, you know, from confusion, it's shorten the time from confusion to clarity.

It's turned onboarding, I would say, from passive exploration into guided discovery. The new team or, you know, the new team member that we have don't feel stuck waiting for someone to explain everything. They can explore it themselves intelligently and and actually build in confident faster.

But I also want to add, though, it also complement the tools almost complement the experience engineer. So even some of the lead developer that we have who deeply understand one area can actually use the tool to gain a broader visibilities across the board. So overall, I would say it's reduced the reliance on the tribal knowledge and accelerate, autonomy for our teams.

Yeah. That's such a good point. It's not just an onboarding tool, but it can also help to level the playing field for everyone on the team.

Exactly. But yeah. No. That makes a lot of sense. And what about for you personally as a team lead? Is there anything that you can say to how you've been potentially benefiting from it?

Yeah. Definitely. I use it every day. So yes. Absolutely. For me, personally, I I it's I call Ord Intelligence is my technical co pilot in meetings.

As a team lead and for partner, I'm offering often in road map discussion, discovery session where someone asked me, is this a small change, or what would it take to adjust this? And in the past, I either would have to defer it back to my lead developers or schedule a spike before I can give any directional answer. And in a complex board like this, it's understandable. But now I can actually run the high level impact review in real time when I'm in the meeting. I can see whether the few touch CPQ logic, revenue automation, APAC classes, or is relative isolated.

It doesn't really replace the technical review, but it give me enough visibility to provide an informed directional guidance without pulling and, you know, engineer team away from the active work.

And it's also help keep my meeting more productive. It's review the context switching, and it build trust with the stakeholder because the response that I am giving them, I'm more grounded in data, not instant. And to me, as a leader, that confident matter a lot.

Yeah. That's so important. No. That's great to hear. So I'm really conscious we're up to time, and I did promise time for q and a, but I have one more question for you.

So what advice would you give to those who are potentially struggling with Salesforce visibility and and maybe on the fence about investing in something like org intelligence?

Sure. Okay. So my advice would be don't normalize the struggle.

In a mature sales portal, complexity compound over time. And if your team spend more time investigating impact than actually building values and that your signal, I think many team accept the complexity, fatigue, a part of the job. That topic is scary. Another one, we're gonna touch the account again.

Only one person understand that automation. That is not normal. That is more an operational risk to me. So the first step is being honest about your work maturity level, your complexity.

If your environment is small, likely customized, fully documented, you may not need it yet. But if your org have evolved over the year, then, you know, your if your where is process and multiple architect heavy impact, then that visibility had be will become critical.

And it's important to think too, like, all the intelligent and a reporting tool. I think for me, it is an architectural risk management tool. It's a real balance of when you're making chain, when it's, you know, when you don't know where the hidden dependency are. So for me, at scale, detective work isn't a badge of honor, to be honest. It is more like a productivity tax. So for me, the shift with the team for us happened when we stopped asking, can we eventually figure it out and start asking how quickly and confidently can we understand the impact.

So if your team spend more time investigating impact than building, and that's your signal.

That's really great advice. Thank you so, so much, Wendy. It has been a really great conversation. And what I think has come through strong in sort of everything you've shared is really just how much visibility changes things, not just around, you know, how your team works, but also how confident they feel, how fast you can deliver, and, you know, even how you as a team lead can show up for your stakeholders. So, yeah, thank you for being really open about all of that.

Thank you, Nicole.

Bless you, dear. You too. Okay. So I'm conscious we're at end of time, but let's answer a couple of questions. So, yeah, if anything has come to mind while we've been speaking, please feel free to pop it into the q and a. I do have one question here for you already, Mindy. To start off with, do you store documentation in other sources like knowledge or confluence at all?

Yes. We do store knowledge in confluence. Yes.

Okay. So the question is, if so, how do you use how do you utilize Org Intelligence with these existing documentation repos? And do you find yourself preferring working with Org Intelligence over your existing docs?

Awesome. So to be honest, the the repo is not a big repo, so we don't have quite a bit. How I'm using it now is actually using Org Intelligence to generate my documentation on some you're kinda catching me up on the lot of the existing process that I didn't have documented. And I actually put it back into Confluence for the team for more on the business processes to give it a little more visibility, but it's not the other way around. Does that make sense?

Yeah.

I think so.

And I would I will say I do prefer using Orton Intelligence just because if I have follow-up questions, especially on, like, an APAC and what it's doing, I can move a little deeper, I won't be able to do that with Confluence because, you know, whatever you have in Confluence, that's what it is. But in all sense, I can keep going many layer deep if I wanted to.

Yeah. No. That's really good. Thank you, Mindy. So it looks like couple of the other questions have already been answered.

They were more about our product. So I think we can leave it there for today. I'm just going to quickly share my screen one more time because there are a couple of QR codes that I would like to share.

And I am just fiddling, so bear with me. And here we go. So hopefully, you can see my slide again. So, yeah, I just wanna again say thank you so much, Mindy.

It's been really useful. And if any of our conversation today has, sparked some curiosity, then, there are two QR codes here on screen for you. On the left, that is a QR code to our org intelligence page, where you can have a look around, a couple of resources, and learn some more about org intelligence. Or if you'd prefer to speak to us, please feel free to reach out.

We'd love to hear from you.

You can scan that QR code on the right, and it will direct you with how you can do so. So with that, I've yeah. We'll leave it there. Thanks, Mindy. We've loved having you, and I hope everyone else has a great rest of their day. Thank you.

Awesome. Bye.