Understanding Data Modelling in B2B SaaS with Kyle Crouse

Vivin (00:02.38)
All right, we live. Cool. Okay. This is the 15th episode of Beyond the Pipeline podcast. I have Kyle Crouse from GoNimbly joining me today. Welcome to the show, Kyle.

Kyle Crouse (00:15.212)
Thank you. Glad to be on.

Vivin (00:18.584)
Great. So, Kyle, just some background of whatever I've seen on you, about you on LinkedIn. You you went on to be a developer, and then from there, you went on to being a DevOps architect. I could imagine how that journey went through. You must have become a developer for those, know, CRM modules, you know, building out a lot of those custom processes and workflows. You know, now that you've moved into more, you know,

the business side of things where you understand where the requirements are coming in from rather than being the side where you're just getting the requirements and asked to do some particular tech work, right? Or developing work. Thinking about it now or thinking about all the requests that came to you. Do you think those requests were more because of mismanagement or because someone out there didn't get their

Kyle Crouse (00:56.056)
Right.

Vivin (01:13.302)
work streams right or the processes right or or do you think there are some places where you you know where development work is actually required.

Kyle Crouse (01:23.086)
Yeah, I do. I definitely remember that period of time where I was more in the developer world and just receiving the requests. And I remember constantly feeling like, Why are you giving me giving me the solution here? Like I, I think you need to define this a little more broadly so that we can figure out the best solution. So definitely, yeah, I can level with like some like mismanagement. Sometimes people come in with

preconceived notions of how they think something should be done. Sometimes there's good reasons behind that and it's good to dig in. But yeah, I think there's some of that. But also, yeah, you have to acknowledge where they're coming from. Oftentimes they have maybe more context than you do with the requests that they're giving. They may know the system a little better. They've been around a little longer. So there's room for both sides. I think you can

You can always dig in and learn a little bit more when you receive a request that doesn't really make sense.

Vivin (02:27.584)
Yeah, I'm sure. mean, I've never been exposed to the developer side of the CRMs, but I'm pretty sure that there is quite a lot of potential. But I feel like there was this one thing that stuck with me the last time we spoke offline where you said that, you know, you're doing a bunch of things that the system is actually not supposed to be doing. Right. So I think you've developed you or you've been involved in projects where you've had some really complex scenarios coming your way.

Kyle Crouse (02:57.038)
Yeah, for sure. That's always been the fun thing for me. And yet you always sometimes you take a step back and you're like, why? Why did we decide to do it this way? But we figured out how to make it work. so why not?

Vivin (03:06.53)
Yeah.

Got it. In your current stint as a consultant, you know, when you're working for a lot of clients, have you seen these developer requests coming or where you think, Hey, you know, I think we need a developer to create this custom module or custom workflow. Or do you think it is something you can manage with some workarounds within the CRM features itself?

Kyle Crouse (03:35.17)
Yeah, I think there's definitely been a trend away from code for sure. think we're seeing and I'll speak most of this podcast. I'll be speaking from Salesforce perspective. That's the system I know best. It's the most customizable system in the CRM space. So I'm definitely speaking from that perspective.

And I think there's definitely been Salesforce Flow in particular has become a lot more capable. Even since I've been in the ecosystem, I see it being more and more. I mean, it's a double edged sword because as it becomes more capable, it becomes more and more like a programming language. You're just doing it with clicks rather than text. So there's the double edged sword there, but yeah, I mean, I...

Vivin (04:23.299)
Yeah.

Yeah.

Kyle Crouse (04:31.116)
I think a lot of the things that I was doing as a developer early on in my career, I would say why we don't need to do that in code. Like it's just not necessary. This is so simple. We should be doing this in flow. There's still definite times. see, I still write a fair amount of code because I see the places where it's most, where it has a strength.

Vivin (04:44.043)
Got it.

Vivin (04:52.492)
Mm-hmm.

Kyle Crouse (04:58.156)
Salesforce is always trying to fill those gaps and see like code is commonly used here. Can we build a tool that does this a little better? yeah.

Vivin (05:08.524)
Yeah. Got it. Yeah, I think we can go on for an entire episode about how the developing side works well and how we could create those custom workflows and processes. But that aside, we are jumping onto today's discussion, which is around data modeling. And before we get into the discussion, Kyle, I thought it would probably make sense for us to lay down what data modeling actually means.

Kyle Crouse (05:35.362)
Yeah.

Vivin (05:36.91)
It's not very complex, but I think it's a decorated term. maybe you could just start off with what data modeling really means in the context of B2B SaaS

Kyle Crouse (05:49.038)
Sure. Yeah. I think, I mean, it's definitely a big topic, but it's how are we planning to structure the data and represent entities within the system? So when we think of like Salesforce or HubSpot even, we have like really core entities. The account is like the core entity in Salesforce contact.

probably the core and HubSpot, also very important in Salesforce. So that is our data model. And then obviously within each, I always think of it as like a spreadsheet. So you have tables and rows. So, and then our columns become the fields, the data points that we want to track. So data modeling as a concept really comes down to how are we going to structure that data? And it gets very interesting.

Vivin (06:18.242)
Yeah.

Vivin (06:28.238)
Yeah.

Kyle Crouse (06:45.326)
When we start to think about structuring things that Salesforce doesn't do for us because we have some custom need for a certain customer. Salesforce provides us an out of the box data model with interrelations and connections between those tables. But there's always good reasons to create custom tables too, so that we can accurately model a specific business. Yeah. And I think

Vivin (07:13.896)
Good. Yeah.

Kyle Crouse (07:14.71)
In our other conversations, we talked a lot about how this does bleed into data quality as well. So I'm sure we'll get into some of that, but data quality inevitably comes in here. Data modeling affects data quality in some ways, and they kind of interact.

Vivin (07:20.814)
Yeah.

Vivin (07:32.492)
Yeah, absolutely. I mean, I think it's, all a subset of each other, right? Like you get data modeling, right? Then inevitably you're going to get your data quality screwed up as well. but yeah, I mean, you know, also since you've been working with Go Nimbly for about four, four and a half years down pretty sure you've, you know, gone into a client project and, and pretty much, I'm assuming that your first step is to do an audit of sorts, right? Like a systems audit, a data audit. and.

I just wanted to understand from your experience. Do you have or some examples or do you feel like where do companies go wrong with this whole data modeling stuff? Right. Do you, do you see a pattern across clients where you figured, you know what? think this is where people normally screw up.

Kyle Crouse (08:16.526)
Mm-mm.

Kyle Crouse (08:26.65)
yeah, I mean, I think it, it definitely varies a lot based off the size and maturity of the business. I think like governance around data model is a pretty big thing that companies probably don't implement soon enough. early on, like, you don't need, you don't want a lot of red tape around just adding a field. Like you probably should just add it. Don't, don't worry about whether or not, you know, you, you've communicated to the other teams, like,

Vivin (08:50.264)
Yeah.

Kyle Crouse (08:57.294)
You should know, maybe do a quick check to see if something exists that could serve your needs, but go ahead and add it. I think, yeah, definitely governance is important. Documentation around a data model and making sure that conceptual integrity is maintained. That's kind of a big thing that I hit on a lot is like, let's get out of the system for a little bit and think about the concepts that we're trying to define here.

and make sure that, okay, if an account represents, I think Salesforce defines it as like just a business that you're interacting with, which is very broad. Typically we think of it as like customers. does it make sense for this data point to live at the, on the customer? Like, does it make sense there? opportunity as well. It's like a deal. Does this data point make sense on the deal object? lots of times you end up with.

Vivin (09:37.038)
Yeah.

Vivin (09:54.702)
Hmm.

Kyle Crouse (09:56.408)
just things getting strewn about and the conceptual integrity is broken at that point. And then at that point, people just don't really understand because they can't really like rationalize through it because there's so much that's just been thrown on. I know you said examples. I've definitely, I've worked with a client before where they had to create a custom object just to hold more account fields. So.

they had reached their account field limit, which is wild. think that the account field limit is close to 1,000 maybe. So they had over 1,000 fields that they wanted to track on the account. And so they ended up creating a custom object that would be linked to the account that would just be an extension of more fields. And that creates so much maintenance overhead. You've got to make sure that record exists. You've got to do a lot more looking up across records.

Vivin (10:26.648)
Wow.

Vivin (10:32.087)
Yeah.

Vivin (10:46.253)
Wow.

Kyle Crouse (10:53.44)
It's just, you know, not a good, not a good situation to get in. And I would say that's a failing of governance and just like general housekeeping of your data. You have to go in and make sure that like, do we still need this data point? Should we like offload it somewhere, archive it because it's just not that useful to us anymore. That's always something to be looking at. And I mean, if it's going to happen anywhere in Salesforce, it's going to be the account because that's what's shared across.

Every team in Salesforce cares about the account. So I guess in one sense it makes sense that it happened there, but definitely not ideal. And I think steps could have been taken to avoid that.

Vivin (11:36.366)
Yeah, mean, thousand fields for a single object sounds insane. Did you guys step in and just like, you guys like go through the pain of going through what those those thousand fields meant?

Kyle Crouse (11:50.458)
Thankfully, I was not too involved with that whole solution build out. It was kind of happening parallel to some of the work I was doing. But yeah, I mean, we've definitely done that sort of audit before. There's a lot of tools out there that will check, like, look across all the fields and determine how many of the fields are populated across every record. That can be super useful to just determine is something being used or not. So yeah, we've done a lot of that work and it's

It's kind tedious and not super fun, but necessary.

Vivin (12:22.818)
Yeah, I'm sure. Yeah, and generally what I've heard is bigger the company, bigger the mess is that your experience as well.

Kyle Crouse (12:35.074)
Yeah, I think that's that generally makes sense. I haven't worked with too many large companies that didn't have a lot of legacy, legacy data, legacy fields. The needs just tend to be more complex. You create more exceptions in a large company. So it's like, well, we're not going to follow this process because it's just too complex to try to create a process that everybody can follow and fit into, which is

Vivin (12:55.096)
Hmm.

Vivin (13:02.295)
Yeah.

Kyle Crouse (13:04.664)
Probably a mistake to just say that that's our decision. Like you should do the work to define a good business process that doesn't, you know, require everybody doing their own thing.

Vivin (13:16.384)
God, it makes sense. And I'm pretty sure, you know, people probably hire you when shit hits the ceiling. So you're probably walking into a mess all the time.

Kyle Crouse (13:22.774)
Yeah.

Yeah. Yeah, I would say less so lately, which is kind of nice. But for sure, a few years ago, I felt like that's what I was always coming into was the mess of the org and figuring out how are we going to keep this thing running and improve it along the way. still, they probably hired us not just to clean it up. They probably hired us because they wanted some big feature project built. so we have to figure out how to

Vivin (13:36.91)
you

Vivin (13:49.102)
Hmm.

Kyle Crouse (13:54.924)
make that happen while, you know, leaving it better than we found it, which is always the goal, but very difficult. Yeah.

Vivin (14:00.79)
Yeah, I'm sure. So for a person who's probably not, let's say, from a tech background, let's say, figuring out the data model. And for me personally, I've always taken an approach from the questions that we want answered, right? And work backwards from there. So let's say, for example, I want to demo requests.

And I want to also look at it from a quarter to quarter point of view, compare those demo requests. Right. So working backwards from there, what I would probably want to get is let's say a field track, the demo request, maybe you have the form submissions data coming through. You probably want to stamp a timestamp stamp a date field on it. Right. And a few more things that helps us track from where these people came in from, which the channels that know.

worked to get these demo requests and things of that sort. So when you work backwards from there, feel it makes sense to one, especially when you're, let's say, going to a company where you've already had some systems and processes and you know it's a huge mess already. Maybe working backwards also helps you prioritize on what you need to work on first, right? Because you might have, let's say, a huge mess.

Kyle Crouse (15:19.352)
Thank

Vivin (15:24.926)
And you might have, let's say, 100 things to fix, but you also need to prioritize. So is that how you would ideally look at data modeling or figuring out what fields you actually require by working backwards from the answers that you need? Or do you have some other ways to look at this?

Kyle Crouse (15:45.346)
Yeah, I think generally starting with the outcome in mind is going to be the best. think also you have to consider like that's going to get you to a very specific path. And it's the important one to keep in mind because this is the like the right now need that we need to fulfill. But also considering the future, like what do we expect for this solution? Are we going to expect to need other things in the future?

Vivin (15:55.693)
Hmm.

Vivin (16:00.899)
Yeah.

Kyle Crouse (16:11.832)
Do we need flexibility? Do we need a lot of flexibility with this solution in the future? we don't know what those future requests are, requests meaning future enhancements to the solution. But we know they're going to be coming. So in that sense, you might build a more robust data model as opposed to just a single data point. To your example, meeting requests,

Vivin (16:37.005)
Yeah.

Kyle Crouse (16:40.62)
meeting request date or something like that. That could be a single data point on an opportunity or a meeting request could be its own table and it gets linked to the opportunity. That's a more robust data model, but it comes with its own maintenance and everything. So you have to find this balance of how do we fulfill the need right now? And lots of times I take an approach of like,

Vivin (16:50.061)
Yeah.

Kyle Crouse (17:07.416)
How painful if I need to go down that robust data model route in the future, how painful is it going to be to switch over? That's often a calculus I do in my mind. And if I kind of think, nah, probably not that bad, I'll go with the quicker solution now and wait for that more difficult request to come in. And then at that point, we can think about how we're going to solve it. So that's one thing.

A couple other questions that came up as I was thinking through this. When I'm defining data points, one big thing I think about is how is this data point going to change over time? Should it change? Or is it something that this meeting request date gets populated and it should never change after that? The computer science term for this is immutable versus mutable.

Vivin (17:59.182)
Hmm.

Kyle Crouse (18:05.248)
immutable meaning, unchanging, mutable meaning, it changes or can be changed. So typically the, if it doesn't change, it's probably like a snapshot in time. It's like, this is what was true at this time and nothing can change that. It's just a historical record at this point versus the changing data point is often what's most current. And from that perspective,

Vivin (18:24.257)
Yeah.

Kyle Crouse (18:33.1)
the changeable data points are usually more useful because that's typically what we want is if you're working in Salesforce, you want to know what's most current. If you're doing like analytics, you're going to want to know the historical trends. But but the changing the mutable properties are harder to maintain, So there's tradeoffs. But more often than not, you want something that's going to change over time and be kept up to date. That's one thing.

Vivin (18:40.856)
Yeah.

Kyle Crouse (19:02.158)
Another thing is what data do I have at the point of creation that I won't have in the future? Maybe I want to log that. For example, like if we have a demo request, the request creation date, like when was this record or when did this request come in? That may not be strictly necessary for what you need to use it for. You probably just need to know who the requester was. When did they request for?

Vivin (19:24.386)
Hmm.

Kyle Crouse (19:31.906)
But that creation data is likely to be useful down the road. It doesn't really cost us anything to store it. So but and we won't have it if we don't if we don't get it now. There's not really any good way to get it back. So there's plenty of other things that you could think of along those lines. And then one other one that I that I had was how can I get more bang for my buck for a single data point? So like

Vivin (19:45.39)
Yeah.

Kyle Crouse (20:01.014)
An example is a checkbox versus a date time field. Sometimes I'll use date time fields as checkboxes. More or less, it's like if this field is populated, then I can consider this true. So for example, tracking if an email is sent. I may only care if it was sent or not. That's a true or false. But inevitably, I'm going to also know, I'm going to want to know when it was sent.

Vivin (20:15.373)
Yeah.

Kyle Crouse (20:31.182)
So if I use a date time there instead of a checkbox, I can kind of get both for one. If that date time sent date is populated, I know that the email was sent and I kind of get more out of that data point. So those are a few things I think through. There's lots of things we could go down, but yeah, those are questions I typically ask.

Vivin (20:32.577)
Yeah.

Vivin (20:49.771)
Yeah, of course.

Vivin (20:55.384)
Got it. Have you reached a point where, know, I'm pretty sure you, must have worked for a lot of companies, right. And looking at the size of the company, you pretty much know without probably even looking at the data model that they currently have saying that, Hey, you know, we're pretty sure this is what you'll need based on the experience that we've had so far with other companies, because we know you're going to go down that route. Right. So, one way I think about it is,

Every company is different. They have different needs. They have different requirements, but you get an overall picture or an overall idea of how it's going to pan out. Right. And, and I think you alluded to this as well, where you said that, you know, they might not need it at this point in time, but you could foresee it, let's say in the near future. And then you would probably solve for it right away. Right. So like you said,

there's probably a fine balance there between doing short term stuff and really scalable long term stuff. So are there some considerations? One I'm pretty sure bandwidth and like you said, the complexity of who's going to manage it. But are there any other considerations to which you would probably say that, I'd probably just stick to what works now rather than building it for the future.

Kyle Crouse (22:18.958)
Yeah, I mean, I tend to be pretty pragmatic with my solution, so I will typically go towards, here's what we're going to need now, and let's try to build a solution that we can iterate on, rather than trying to build everything right now. Yeah, I'm trying to think of if there's anything else I consider. Yeah.

Vivin (22:26.222)
Hmm.

Vivin (22:41.494)
I think it also depends on the people on the other side. Let's say, for example, if you have a client who, know, within your conversations, you felt like he knows the systems pretty decently and you build something scalable, he's going to be able to manage it. Right. And he's going to be able to understand what you've created versus let's say you're building it out for someone who has absolutely zero clue of what's happening currently.

you would say, okay, you know, I don't think that's going to work because I'm going to have a difficult time explaining it to the person in the first place.

Kyle Crouse (23:13.026)
Yeah. Yeah. Yeah, that's a super good consideration. The long-term maintenance of a solution is really important and we don't often consider it, especially working for a consulting company. We typically have a lot of deep technical skill in-house, but our clients often don't. A lot of clients we have have a pretty young Salesforce org or they're just young companies in general, so they don't

Vivin (23:30.67)
Hmm.

Kyle Crouse (23:42.478)
They haven't had the need to hire like a Salesforce admin or anything like that. So definitely thinking about how can we build solutions that they'll be able to maintain long term so that we don't have to always be there maintaining their solutions. That's never really the goal for us. We want them to be self-sufficient over time.

Vivin (24:04.494)
Yeah, got it. And the more I think about it, let's say if I was handed a CRM, like completely fresh, right? And I've never been in a position where I've like onboarded a CRM and I have the first person to touch the CRM. I've always inherited CRMs or systems. But had I been given that opportunity, I would have made sure to...

understand the standard objects and standard fields much better than how I have it today. Right. A simple example should could be, I know that, you know, you're mostly coming from a Salesforce background, but on HubSpot, there is something known as life cycle stages, which is built in and you know, it's your basic stuff, right? So if you have a lead, you have subscriber lead, marketing qualified leads, sales qualified lead opportunity and customer. think there's one more level below customer, I think.

But anyways, the point being that there are a lot of reports, a lot of systems that is built around that single property within HubSpot right now. A lot of times what happens is people ignore those standard fields and end up creating their own custom fields based on what is required for them, you know, on what they're to or what they have built in the previous organizations. I feel like there is value in what

Kyle Crouse (25:10.658)
Mm-hmm. Yeah.

Vivin (25:29.666)
you know, systems and tools give us offhand like what that is there out of the box. And it's not like I know a lot of people say that, you know, you shouldn't allow the tool to dictate your process, but it's another thing to basically say that, you know what, let me understand what is already given. Let me figure out what is the best I could use with this and then move on to building custom fields, right?

Kyle Crouse (25:33.474)
Yep. Yep.

Vivin (25:57.518)
What has your experience be that I'm not sure if you've had the opportunity to build out CRMs from scratch. But have you seen that playing out where you try and figure out, you know what we have, let's 50 standard fields and let's make sure we use those 50 standard fields to the best of our capabilities because there's a lot of other systems that are already there for us to leverage if that is used.

Kyle Crouse (26:20.974)
Yeah, totally. Yeah, definitely. When you choose to go outside of the out of the box, that should always be done with a lot of consideration. And yeah, to your to your point of like, don't let the tool dictate the process. I think it's a little more complex than that. I think if you're a large company, probably yes, don't let it dictate your process. If you're a small company.

you're probably better off letting the tool dictate your process, especially if it's something like Salesforce or HubSpot where like, this is a vetted tool that they're probably, they have a certain process because it's worked. So it can often be good to, to kind of change your process to fit the tool when it's easy to do. If it's super hard or you're going to see like really adverse, like customer experience ramifications out of some process.

Vivin (26:49.496)
hehe

Vivin (27:00.984)
Yeah.

Kyle Crouse (27:16.994)
Yeah, probably consider customizing. But yeah, to bring it back, I always think about like systems have a certain view of the world and they will be more useful to you if you take on their worldview, at least when you're working within the system. Obviously, it doesn't have to be the worldview that your company has for data or any or that sort of thing. But when you're working within the system. So I already mentioned like Salesforce

Vivin (27:17.304)
Mm-hmm.

Vivin (27:37.23)
Yeah.

Kyle Crouse (27:46.616)
kind of centers everything around the account. That's super crucial to understand when you're building just about anything in Salesforce. HubSpot centers almost everything around the contact. And then Jira, as another example, like everything's an issue. Like you typically have this core entity in the system that everything kind of just revolves around and supports. So it's helpful to understand that.

Vivin (27:49.058)
Yeah.

Vivin (28:06.872)
Yeah.

Kyle Crouse (28:15.564)
I don't know if there's like a good way if somebody was like, well, how do I determine what that worldview is? I don't know if there's a good way or I don't have any secret trick. It's just kind of experience. Talking to experts is always going to help you. But yeah, if you're choosing not to use their standard fields, you're typically giving up functionality that they built around that field. Not always. Salesforce has plenty of like fields that are standard on the opportunity. They're like, what's the

Vivin (28:21.774)
Thank

Vivin (28:29.294)
Yeah.

Kyle Crouse (28:43.992)
point of this. Like I don't really get anything out of it. It's more you just like, this seems like something you'd need. But like an example would be you could opt to create your own amount field on the opportunity. Nothing's stopping you from doing that, but you're going to give up a lot. There's also a lot of limitations that come with the amount field. Like you can't set it directly if you have opportunity products associated.

Vivin (28:46.07)
Yeah.

Kyle Crouse (29:12.278)
And that's by design, like they want the amount to always be accurate. So they calculate it for you. So yes, you could create your own, but then you're giving up the automatic rolling up of that revenue. So if you're going to do it, just be aware of what you're doing, be aware of what you're giving up. Sometimes it's the right solution. Sometimes it's not. With the amount field, that tends to be a

Vivin (29:12.44)
Hmm.

Kyle Crouse (29:38.574)
an interesting one too, because a lot of companies are more interested in like annual contract value or ARR, annual recurring revenue. So they start to store that in the amount field. And in my mind, you're not using the amount field properly at that point. You probably do need a custom field, but yeah, I'm going a little bit too deep on that one specific example. there's like, you just need to know that if you're going to throw out that functionality,

Vivin (29:58.636)
Yeah, I got it.

Kyle Crouse (30:07.692)
You're kind of on your own at that point. Salesforce is going to let you do it, but they're not going to help you too much if you decide to do something that kind of paints yourself into a corner.

Vivin (30:19.358)
Yeah, I think in most cases what happens is the example that you are giving most people will not know that amount rolls up into opportunity product and because they probably not explored the product side of things. And when they do eventually get there is when they figure out that, you know, we should have used the default of the standard amount field rate. And I've noticed that a lot of times where people go ahead and build their own custom fields and then

when they pick up another feature within the same tool, they figure out, OK, fine, you know, this would have worked out better with the standard field. And I also feel like there's also this inclination for people to go complex right from the get go, you know, where people want to make things, let's build out things on their own and make it look or, you know, stamp like an identity on the platforms that they work on. I feel like that

Kyle Crouse (31:13.006)
Yeah. Yeah.

Vivin (31:16.59)
that plays out in one way or the other for certain folks as well or certain companies as well, right? And I think, so maybe moving on from standard objects, right? Let's talk about creating custom fields, right? And obviously I think, like you said, once you have understood, and I'm pretty sure there's a lot of documentation that

Kyle Crouse (31:25.646)
Mm-mm.

Kyle Crouse (31:37.688)
Mm-hmm.

Vivin (31:44.846)
Salesforce and Hub support provides in terms of how those standard objects work. make sure to go through those, understand the documentation, understand what it leads to. But let's say that you've explored the entirety of the standard fields and objects that you have, right? What are the considerations sets you should be having for, let's say I'm pretty sure you're moving out of the standard fields because you have a custom use case to solve for, right? So sometimes it feels like it's pretty straightforward.

Kyle Crouse (32:00.355)
Yeah.

Kyle Crouse (32:08.462)
Mm-hmm.

Vivin (32:14.272)
of forward, Just create a field like you said earlier, there's not a lot of red tape around it. But like you also said, a lot of those fields are interconnected. Like if you're creating a field on the lead object, you should also figure out what repercussions it should have, let's say on the contact object, should it move onto the contact object on conversion? How does that play into account object?

Kyle Crouse (32:21.646)
Mm-hmm.

Kyle Crouse (32:38.285)
Yeah.

Vivin (32:42.19)
Do you need it for reporting from an account to contact as well? Right? So I think there's a lot of questions that needs to be answered. And it's not just about creating a single field within an object. Right? So how do you look at that? Like what are the considerations that you would probably look at? And how do you figure all of this entire web that you will have to go through before creating one?

Kyle Crouse (33:09.89)
Yeah, I mean, if we're thinking about when do I need a custom object, like a new table versus just a field, some symptoms that you might see, like the main one that I think of is if you have this group of related fields on an object, so we can take it back to our meeting request.

Vivin (33:39.191)
Hmm.

Kyle Crouse (33:39.618)
Maybe I don't care about just the first one. I now care about multiple meeting requests or I want to know like when the meetings have been held. So now at this point I may have like meeting date one and meeting date two and meeting date three and then and then like, okay, we're just tracking dates. That's fine. But what about when I want to track more about those meetings? So like meeting attendee like I don't know, meeting attendee one meeting attendee two.

Vivin (34:07.233)
Got it. Yeah.

Kyle Crouse (34:09.758)
at that point, you're starting to see the need for like, this needs to be its own table. because we're tracking, these are related fields. and what happens when I want to have, I want to track more than three or whatever. I ended up having to add like, you know, three fields every time I want to track one more. and it just, when you're in like building automation around fields like that is very painful.

Vivin (34:15.704)
Yeah.

Vivin (34:38.37)
Yeah.

Kyle Crouse (34:38.926)
because you can't just, at least the way Salesforce thinks about things, you can't really like loop over fields and run the same process on each one. You kind of have to build separate processes for each set of fields, which is super painful versus if it's in its own table, I can just loop over each record in that table and do the same thing to each of them. It just ends up, I mean, it also comes with...

maintenance. Like there's trade offs to all of this stuff. If, if you can say like, I'm only ever going to need to store two meetings or whatever. Maybe you're in a place where you can do that and just store it on the opportunity or the account. But I know that I'm pretty, I'm a pretty bad predictor of, you know, when, how I think things are going to go in the future, or at least I've seen enough worked with enough clients where they're like, no, I'm only going to need to. And it's like,

Vivin (35:09.39)
Yeah.

Vivin (35:22.915)
Yeah.

Vivin (35:30.478)
Hm.

Kyle Crouse (35:35.992)
you know, three months down the road. Sorry, we need three now. But that, so that's like one side of it. If you're thinking about totally custom entities, there are like interesting use cases where it almost fits into a standard entity, but then it doesn't quite. I've seen that a couple of times with things I built.

Vivin (35:36.334)
Right.

Kyle Crouse (36:03.404)
Yeah, so like questions I'm asking, like, does the use case fit the standard object that I'm looking at? Does it actually, and then bring it back to conceptual integrity, like if Salesforce says this is what this object is for, does that still fit what I'm trying to use it for? Or am I just trying to gain access to some functionality that they give me through this object? And I'm kind of like shoving it around, back into a square hole.

Vivin (36:11.096)
Hmm.

Vivin (36:27.118)
Hmm.

Kyle Crouse (36:32.334)
An example that I have is like, I built out a solution that allowed one of my clients to mass send emails to customers on a regular basis. And it was the source of the emails, the data that was included in them was like integrated from some of their custom systems. had a whole proprietary solution where they were sending in things that customers needed to be notified about. And, you know, that looks a little...

a lot like a campaign in Salesforce. It's like you add your campaign members and you have an email template. They each get that. We could have gone that route. Probably. We chose to go a fully custom data model. Some of the reasons that we chose to do that were because our email template was very complex. It was pulling in things from multiple data sources.

Vivin (37:04.364)
Hmm.

Kyle Crouse (37:29.184)
Ultimately, we're sending to an account, not a contact. And campaigns kind of allow you to add accounts. I think they did add that feature, but not very well supported. We were sending sometimes to multiple contacts on an account and it was going to get crazy if we tried to do that. So there were just some things that didn't fit. for that reason, we chose to go fully custom with it. It was a pretty complex build, but this was a super mission critical process within the company.

Vivin (37:33.356)
Hmm.

Kyle Crouse (37:59.446)
and for that reason, like if we'd gone with campaigns that almost would have been a liability because we would have lost out on some flexibility. which is a big thing. Like if you're going to go custom, you get flexibility cause you're building it all yourself. If you're going to go with something that's out of the box, you're going to lose flexibility, but you'll probably get up and running quicker because they're giving you a lot of the functionality you're after. So it's always this long-term short-term,

Vivin (38:06.486)
Hmm.

Vivin (38:14.413)
Yeah.

Kyle Crouse (38:28.812)
debate that you have to weigh the trade offs of each. Never really a clear cut answer. So I feel like I keep bringing that up. It's never a clear cut answer. Yeah.

Vivin (38:29.006)
Yeah.

Vivin (38:36.824)
got it. Yeah, I'm pretty sure I mean everything in I think in whatever we do is options. You probably don't have like 100 % answer to saying that this is what works for sure. But I was just curious as you were saying, you know, about the considerations about moving to a custom object and then the particular example that you were talking about. Do you go back and document like once you implement the

custom object, things of that sort. Do go back and document from the details of why we didn't use the standard field or let's say standard object in this case and why we did want to use custom object, how to use those custom objects. Is that something that you do post you implement or do you just try and explain what we've created in the custom object and how to use it? But do also look at why we took the decision that we took?

Kyle Crouse (39:36.93)
Yeah, I think that's super important documentation to have. I won't say that I always do it consistently, but yeah, I mean, I'm pretty frequently writing solution documentation and especially, I do it especially when I'm evaluating different approaches. So laying out, here's the goal we're trying to achieve, here's the solution we're going with, and here's like two or three alternatives that we considered.

Vivin (39:53.134)
Hmm.

Kyle Crouse (40:04.002)
That's really valuable, especially from an architecture perspective, being able to see those decisions that were made and why they were made that way. It also gives you a good launch point to discuss with others because they can kind of look at that and think about, OK, does that make sense? What assumptions are you making in that decision? So, yeah, definitely documentation around that, because it's always like the why that you'll never find just looking at the system, you know, you can you can.

Vivin (40:08.002)
Yeah.

Vivin (40:30.966)
Yeah. Yeah.

Kyle Crouse (40:33.548)
Determine a lot just by doing a system audit getting in there exploring that tells me what it does It does not tell me hardly anything about why it was built that way as opposed to some other way So yeah

Vivin (40:47.822)
Yeah, got it. Have you faced, I think one thing that I've heard about custom objects is integration issues, right? Because a lot of these tools like the external tools integrate with your standard objects, right? Like your leads, contacts, accounts and ops, right? So do you take that into consideration? Like for example, if you're creating a custom object that requires integration or needs tools, sorry, data coming in from external tools, maybe not now, but.

you might you could expect it coming in later. So have you faced those challenges or have you used that in your consideration set?

Kyle Crouse (41:26.956)
Yeah, I think that depends a lot on like what level of, I think it depends a lot on the tool you're integrating with. some tools are going to operate more like the business level. if I think about like Gong, which integrates really tightly with Salesforce, but they're not, it probably has some functionality to bring in custom objects, but they're typically looking at opportunities and accounts because they know here's how this object works. Here's the data that's stored in here.

Vivin (41:34.359)
Yeah.

Vivin (41:52.014)
Yeah.

Kyle Crouse (41:57.05)
but if I'm thinking of like a more flexible integration tool, they typically don't have too much issue with bringing in custom objects, but it's, it's like, they're not going to know what that object means. That's kind of the big differentiator. It's like, gong brings in the opportunity because it knows, it knows what an opportunity means and knows the purpose versus custom objects. you'll have to kind of explain it, but.

Vivin (42:13.112)
Hmm.

Kyle Crouse (42:26.574)
Salesforce, mean, Salesforce definitely has done a lot of work to make, to try to make custom objects feel very similar to standard objects, or maybe the opposite way. They try to, they try to make them operate on the same level. So if we're thinking about APIs that are going to be doing that data, data moving or retrieval, I can retrieve an account just like I can retrieve any custom object. It's just a different query. So

Vivin (42:42.104)
Yeah.

Kyle Crouse (42:56.376)
From that perspective, most integration tools shouldn't have an issue with it. Or if they do, it's probably because they're operating at a higher level and they aren't really designed to bring in custom objects too much. But yeah, mean, there's trade-offs there. If you have some data you need to get into that tool and it doesn't know anything about custom objects, you might have issues.

Vivin (43:14.574)
Yeah, I'm sure.

Vivin (43:22.154)
got it and and you know I think duplicate data is always an issue for a lot of companies right and I think the rule of thumb is obviously you know have systems in place and if duplicates to come through try and figure out the root cause and then of course merger remove them from your system right but I think you and I also discussed about when duplicate data could actually prove useful

across objects, right? So could you please elaborate on that? Where have you seen that being useful? How does that help?

Kyle Crouse (43:58.806)
Yeah. Yeah. Duplicate data and maybe to define what we mean by that. I'm not really speaking about like duplicate records within a table. That's like categorically bad data. Not something that I can see any use for. I think we're speaking more about maybe my account and contacts. I want to roll up information onto the account.

Vivin (44:10.092)
Yeah, that's junk for sure.

Vivin (44:27.256)
Yeah.

Kyle Crouse (44:28.878)
which is in some way it's derived data more than it is duplicate, I guess. You're kind of aggregating and calculating. But in some ways it is duplicate. Or maybe we need to like pull in a data point to live on, maybe it's looking up. So this might actually be a better example. I want to pull an account data point onto the contact that lives underneath that account.

Vivin (44:34.413)
Yeah.

Kyle Crouse (44:58.562)
That is much more like duplicate data. Those two, that's two data points that are identical living in two separate places. And in that case, I think the bottom line is whenever you introduce duplicate data, you introduce risk because there's always the risk that the duplicate gets out of date. And then at that point,

Vivin (45:16.462)
Hmm.

Kyle Crouse (45:25.88)
you've got problems if you're operating off of that data as if it's always accurate. There can also be confusion around where the source of truth is. So what if I think that this contact data point is where that data point lives, but it's actually the account, like that's the source of truth. So there's always risk involved with it. It doesn't mean that it's always wrong. There's lots of good reasons to do it.

Vivin (45:46.807)
Yeah.

Kyle Crouse (45:55.928)
For example, performance is a really common one. Sometimes you can have performance issues because you're trying to join data across several different tables. And that just can be very performance intensive as the data set grows. So sometimes we copy it. That's often called caching the data point. We're going to have it over here, so we don't have to go way over here to get it. But again,

Vivin (46:23.81)
Yeah.

Kyle Crouse (46:24.526)
the out of date thing comes into play. And then another reason that you might copy it is to make it visible within another system. maybe Salesforce is using a data point out of the data warehouse that's received from the product or something like that. So we're going to copy it into Salesforce so that people in Salesforce can use it and they don't have to jump into some analytic system or product or whatever.

Vivin (46:36.61)
Yeah.

Kyle Crouse (46:53.954)
Yeah, but I think maybe to dig in a little bit to the derived data piece, it's always useful to think about what's raw data versus calculated data. So for example, we have like on a quote line, you have a unit price. That's going to be a raw data field that's going to live out the quote line level. But then at the quote level, we have total price, which is the aggregate of unit price times quantity.

Vivin (47:05.422)
Yeah.

Kyle Crouse (47:24.012)
any discounts, all of that. yeah, that's always useful to think about, make that delineation. I mean, aggregate data is super, super valuable. So lots of good reasons. I don't think I need to describe why that's useful.

Vivin (47:40.128)
Yeah, yeah, I think the other reason is also, you know, why I would probably have the same data and let's say an account in a contact object is, is for pulling out reports, right? Like I'm, yeah, mean, accounts with contacts is already a standard report in Salesforce, but let's say if you're looking at a more complex stuff, you'd probably want the data in a single object rather than having to, let's say, create different report types.

Kyle Crouse (48:03.928)
Yep. Yep.

Vivin (48:05.698)
that combines multiple objects, which kind of gets complex for someone who's not very well versed with Salesforce. But having said that, I've always wondered as to which object you choose to create a particular field. Let's say, for example, I'd probably want to figure out the size of an account. So let's say in terms of the employee size or revenue size.

Where would you create the original feel right? Because I could have the contact level, I could have the account level. If it's at a contact level, I could roll that up into an account or let's say from an account to let's say down to a contact and lead. Right. And, and in Salesforce, typically account and contacts work better than account and leads. So then should I have it on leads, have some matching rule, something of that sort. So,

Kyle Crouse (48:51.703)
Yeah.

Vivin (49:04.118)
I mean, logically, would seem that all account attributes to should go within the account object. But is that the only consideration or would you look at it in any other way operationally?

Kyle Crouse (49:18.83)
Yeah, mean, yeah, definitely that bringing it back to conceptual integrity. It should live at the account level. Definitely like otherwise we're going to be copying it to all contacts, you know, that that live under that account. And then what happens when a contact moves accounts? We have to update it and all of that.

Vivin (49:25.038)
Hmm.

Vivin (49:34.242)
Yeah.

Vivin (49:41.666)
Hmm.

Kyle Crouse (49:42.508)
The other thing is thinking about the relationship between accounts and contacts. It's one to many. So one account has many contacts. Well, then if we want to roll that up to the account, how do we, we need to do some sort of aggregation, likely, or if we assume they all have the same value, we just pick one random contact and grab the value, but that doesn't seem ideal. It seems a little strange. So, yeah, mean, conceptual integrity.

Vivin (49:56.749)
Yeah.

Kyle Crouse (50:10.796)
Sometimes there's like, if we're integrating data from another system, pulling in a data point, there can be reasons. Maybe that other system doesn't have any notion of accounts and it only has contacts. It's going to be easier probably to push that data point onto contacts than it is onto an account. can, yeah. I don't have a great example on that one, but so it's, it does come back to like, yeah.

Vivin (50:30.947)
Got it.

Vivin (50:36.62)
Yeah, I mean, I think it's pretty straightforward.

Kyle Crouse (50:39.67)
other systems think about things differently. So do what's pragmatic in that situation.

Vivin (50:46.626)
Got it. Yeah, I think the last bit that I want to discuss on this topic is largely around enablement, right? Like you could have architected a great data model, you know, but at the end of the day, you should be able to explain all of the data model, what goes in where, why this is places where, you know, you need to update this particular field and it automatically gets updated in another object that these are related to each other. A lot of times one,

people might not be too invested in understanding the data model. They, they will probably just want to look at the data model from the point of view of what, is relevant to them. right. So, do you have any tips? So I'm pretty sure documentation is one thing. but have you seen something that works that helps adoption across the YORG and see, I'm going to, at end of the day, it comes down to, individual level interest, individual level.

curiosity, right? So, but just want to understand from your experience. Have you seen something that works that sticks?

Kyle Crouse (51:54.476)
Yeah. I mean, sometimes it's just the engaging, how engaging you are when you present it. Like if you start with the like, what's in it for me, that's going to probably, okay, I'll listen because here's why this matters to me. you know, like screen share walkthroughs can be really helpful. Somebody, some people will watch a video sooner than they'll go and read a bunch of text. lots of visualization.

Vivin (52:06.776)
Hmm.

Kyle Crouse (52:27.662)
I also think like if we can design the system that it doesn't require a crazy amount of documentation that lives outside of the system. Can we make the system more helpful to our users so that things are just more, more natural and presented to them when they need to see it? I know in, in Salesforce, like screen flows have gained a lot of popularity and become more and more useful.

Vivin (52:40.205)
Yeah.

Kyle Crouse (52:57.614)
And that's effectively a step-by-step guided process. So I'm using those more and more just as a way to make the system even more helpful. And even then, maybe you can bring the documentation closer to the user so that it's there when they have a question, or even create a screen flow that doesn't do anything but has the documentation in it.

Vivin (52:57.889)
Yeah.

Vivin (53:21.72)
Yeah.

Kyle Crouse (53:27.534)
And, you know, some steps are just like, here's the steps. Maybe others actually allow them to do things and that sort of thing can be helpful. Yeah, I think as I'm thinking about it, that's probably the main thing. I think it helps a lot when you, as the builder, have your clear on your, how you've designed the data model.

Vivin (53:28.078)
Hmm.

Kyle Crouse (53:56.63)
That helps a lot with communicating and not just like the conceptual definition. I keep beating that drum, but conceptual integrity, but also like the life cycle is really valuable to know of an entity and a field. like for if we're looking at a record, when does this get created? When does it get updated? When does it get deleted? What are the stages it goes through? Obviously we have that.

Vivin (54:10.006)
Hmm.

Kyle Crouse (54:25.358)
for opportunities, but are there stages for these other leads have their own stages as well? And then a field, you can do kind of the same exercise of like, when do we expect this field to get populated? Can it be cleared out when it's populated? Just like thinking through all of that stuff. And then from there, I think you can kind of strip out pieces that are less relevant to people, but it gives you a high level overview.

Vivin (54:40.055)
Yeah.

Kyle Crouse (54:54.99)
And obviously you can create visualizations and all of that around it to communicate to your users.

Vivin (55:01.165)
Got it. Kyle before we proceed, I want to make sure we're like the the time is over, but do you have a hard stop or can you go over by another five, 10 minutes?

Kyle Crouse (55:11.16)
Confirm, I think I'm good to go over. Yeah, I'm good.

Vivin (55:16.802)
Perfect. Okay. So just, just, just when you were saying that I was wondering, you know, I've had multiple instances where I've had to create fields for just a one time use, right? Let's say for example, I have an event upload and there is a field that is not there in my existing data model, but they want to capture it for, let's say a sales outreach, which is applicable only for that particular event. Right? So in most cases, what you end up doing is you end up creating that field.

But what happens after that is you end, you did not end up deleting that field because obviously there's data for, let's say a certain set of contacts, right? So that pretty much becomes redundant for the rest of the time, right? So how have you looked at that? Would you probably then try and merge it with some other data point? Is there a framework that you'd use to tackle these things, right? These very short term?

fields that you need to create.

Kyle Crouse (56:18.402)
Yeah, to make sure I'm understanding correctly, you needed the field for a pretty specific set of contacts, but it's going to be blank and not used for anything else. I don't think that's necessarily a bad thing.

Vivin (56:22.712)
Yeah.

Vivin (56:29.453)
Yeah.

Kyle Crouse (56:36.34)
And yeah, I think there's just like room for it's kind of like general maintenance and housekeeping for an org, whether you decide to delete that. I mean, it does have value. It just doesn't have like broad applicable value for all records, which is totally there's always data points like that. Yeah, I mean, I don't know that I would have like general principles other than, you know, revisit.

Vivin (56:53.869)
Yeah.

Kyle Crouse (57:03.288)
your field to revisit your data model and see if there's things you can clean up over time and archive the data if you don't need it anymore. Yeah.

Vivin (57:05.816)
Yeah.

Vivin (57:15.094)
I think it all comes back to understanding your data model best, right? Because normally what happens is people shift companies. They don't really understand what exactly a particular field means. So when a person does come in with a request, if you're not really well versed with your data model, what fields you have, you probably going to end up creating new or newer fields. And that's how I think this entire spin cycle of, you know, creating those redundant fields comes through.

Kyle Crouse (57:41.56)
Yeah. And it, mean, it gets even more complex too, when you think outside of the system you're looking at, you know, like, do we, if we look at the whole business, is there somebody tracking this data point? that's tricky. And there's a lot of tools coming out for that sort of thing. I think they're called like, like data lineage tool would be a sort of thing that's trying to trace like, okay, this data point here's, here's the lineage of it. Like here's where it came from. but then

Vivin (57:52.749)
Yeah.

Vivin (58:08.183)
Yeah.

Kyle Crouse (58:10.83)
The other thing would be like a data catalog that there's tools out there for that Which sounds super useful? I've never seen one used to the business but sounds so valuable to be able to like jump in and and type in like I Imagine you can do some interesting natural language stuff. We're like, are we storing this data point anywhere? And yeah, it sounds kind of like the dream, but I've never seen it implemented. I've only heard about it. So yeah

Vivin (58:28.129)
Yeah.

Vivin (58:37.056)
Got it. Yeah. Yeah. Makes sense. Makes sense. Cool. Cool. I think we'll probably wrap this up now, Kyle. You know, I think we could go on for a lot more with the same topic, but I have an ending segment, is which is nothing related to what we've discussed so far about three random questions. One is what's the one true that very few people agree with you? It could be about ops. It could be outside of ops, but I'd leave that up to you.

Kyle Crouse (59:05.752)
Yeah, it may not be a surprise, my answer, but don't be fearful of code. It's not categorical tech debt. Code has its use, and I think there's a little too much fear around it. I think it's very valuable. Even if you think about today with large language models being able to write and explain code very well generally, I think that enables a lot of people to be more

Vivin (59:21.612)
Hmm.

Vivin (59:31.374)
Yeah.

Kyle Crouse (59:34.936)
code savvy than they were before. I think the fear doesn't need to be quite as high. It is, you know, it's a technical thing. Be cautious with it, but don't be too scared.

Vivin (59:45.431)
Yeah.

I think there is just a general aversion for something that doesn't look English or doesn't look visually appealing. So, but I think that's what probably helps with now to make it plain English.

Kyle Crouse (59:56.27)
Yes. Yeah.

Kyle Crouse (01:00:04.066)
Yeah, for sure.

Vivin (01:00:05.998)
So there's also like, you you brought up the topic about AI, you know, everyone's talking about how things are going to change. What do you think is not going to change in the next five years?

Kyle Crouse (01:00:17.708)
Yep. I'm going to go right off my last answer and say we're still going to be writing code to meet ops needs for a long time. I don't think we're moving to a place where code is completely unnecessary. I think that point and click tools are very valuable and have their place and becoming stronger. But I also think there's always going to be a bit of a swing back and forth between like

this point and click tool got us into a big, a huge amount of trouble. cause we didn't really think through things when we were writing them. We just kind of pushed it out, built it and pushed it out. And then there'll be like a bit of a swing back to code. code is still like the most flexible, tool we have for, for writing software. So I don't, I don't think it's going to go away.

Vivin (01:00:49.891)
Yeah.

Vivin (01:01:05.975)
Yeah.

Vivin (01:01:10.58)
Yeah, I completely relate to that because every time you think there's a technology out there that's going to solve all of your problems, you're probably going to find some issue with that tech and then you're to have to go back and code it. And of course, someone's got to code the thing that helps you code, right? So, so even even so, yeah. And yeah, it's all go to the bottom.

Kyle Crouse (01:01:27.554)
Yeah, that's right. Yeah. It's all code at the bottom. Yeah.

Vivin (01:01:35.79)
And the last one, Kyle, which is what quality do you think is most critical for ops folks? Is it creative thinking? Is it communication? Is it speed to execution? I'm hoping it's not code this time.

Kyle Crouse (01:01:50.12)
Yeah, it is not code. Yeah, I think communication, and I say that because I think you kind of get creative thinking along with it when you are good at communication. And I'm speaking specifically about written communication, though certainly other types are very important as well. But written communication, writing is thinking in so many ways. When you start to put your thoughts down on the paper or

Vivin (01:02:01.582)
Hmm.

Vivin (01:02:15.938)
Hmm.

Kyle Crouse (01:02:19.616)
on to type them out. It exposes the gaps in your thinking. It exposes how much you understood what you thought you understood the moment you start to take it out of your head. So writing is thinking. think you, and as you write things out, you often think of new ideas and different angles that you didn't think of before. So communication, I think, is probably the most important.

Vivin (01:02:48.172)
I think I just had a deja vu of my orientation with Amazon. So I worked with Amazon and then they have writing as a, as a major part of their culture. And they went through the same line that he just said, where you said that, you know, it helps you with those thinking and help you with those gaps. And honestly, I think that is true. I mean, I took up writing specifically when I was hired by Amazon and it really helps you with clarity of thought.

Kyle Crouse (01:02:54.178)
Yeah. Yes. Right.

Kyle Crouse (01:03:03.97)
Yeah.

Vivin (01:03:15.438)
and you figure out, you know, think this particular thing is missing now that I'm writing it down. But yeah, absolutely agree.

Kyle Crouse (01:03:20.214)
Right? Yeah, was Amazon was definitely running through my mind as I was writing that I know they have a big writing culture. And it's Yeah, I mean, it's also helpful to that. It's it's not just like, quick short chat, you know, it's not just like slack. We write a lot. But it's they have like a pretty long form writing culture, which is super helpful. And yeah, another person that comes to mind like Paul Graham is a big is a big thinker in that.

Vivin (01:03:27.954)
Mm-hmm.

Vivin (01:03:37.204)
Yeah, yeah.

Vivin (01:03:44.77)
Yeah.

Vivin (01:03:48.45)
Hmm.

Kyle Crouse (01:03:49.23)
whole world. has a lot of like blog posts, essays on writing his thinking. So yeah.

Vivin (01:03:56.718)
Yeah, at Amazon, I mean, it was helpful, but it was also annoying where you probably were not the one writing it, but you had to read a bunch of documents written by others. So that, used to become annoying at some point, but yeah, I mean, all said and done, think netnet, was all positive.

Kyle Crouse (01:04:08.238)
Yeah.

Kyle Crouse (01:04:16.398)
Mm-hmm. Yeah, for sure.

Vivin (01:04:18.168)
Cool, cool. All right, so I think that is our time, Kyle. Thanks a lot for this. Thanks for hopping on. And I'm pretty sure our listeners would understand data modeling a bit better now. And Kyle, if someone would like to connect with you, is LinkedIn the best way?

Kyle Crouse (01:04:38.53)
Yeah, LinkedIn is great. My email is kyle.crofts.gov.nb. So you can always reach me there too.

Vivin (01:04:45.068)
perfect I'll make sure to put those two down on the show notes and yeah you have a great day ahead Kyle thank you for doing this

Kyle Crouse (01:04:53.528)
Yeah, thanks for having me, Vivin. This was fun. Bye.

Vivin (01:04:55.374)
Cheers, bye.