Meeting Transcript

Hey

Hey guys.

Hey all.

guys. Hey

Good afternoon.

Good afternoon.

Hey.

Chris.

Um, I'm hoping

Hey, what's up Brian?

How you doing?

Doing good. How are you?

I'm great. Appreciate it.

Thank you for joining us. I'm looking forward to this discussion. It feels like I every time I talk about this, I talk about like one slice of it and here we are all together. Um, except for Kusha who should be here any second. I'm only thinking her. She's an important hog in the wheel here. Um, while we wait for Kusha, we might need just do a quick round of intros for folks that don't know each other. Um, can I'm just going to pick on I'm just going to pick on names and if you know, you can tag someone and go next, that'd be great. So Ryan, why don't you just go first?

Sure.

Sorry,

I'm Ryan, President of Goodwood Consulting. We've been working with Greenbox since 2019 in the spot administrative capacity. So that's us.

who did you pass the ball to you? Okay.

I can go I can go next. Uh

Chris you're you're smiling at me.

yeah Chris Chris go lightly VP of sales over Green Box Capital. A main user of hub spot with Ryan and probably the main causer of confusion at this point. So happy to have everyone here to help you clear that up. Uh let's kick it over uh Brian. I love your your picture that you have on the screen. We'll go to you.

Brian Murray, basically Enterprise Solutions architect been consulting with Greenbox for going on almost five years.

Thank you. Oh, okay, I'll kick it at the nova.

Everyone, I'm Nova Gulea. So I'm senior data engineer at Greenbox. This is my third week at Greenbox.

So so he has all the answers cuz he's the newest and we're just going to give him all the assignments. Okay. Uh, Kusha, I think everybody knows Kusha but

Hi, I'm

Hi Chris.

Okay.

yeah.

Okay, everybody knows me. Um, Steve, do you want to give your uh quick intro?

Steve Hunt's program project management reporting to Sarah didn't been with Green Box about a year.

Steve's going to help us capture items if we need anything best discussion today as well. Okay. So, I actually would like I would like to start big picture here. Chris, maybe you can set the stage of what we're looking to do for the year and Then, you know, perhaps we would also need a quick workflow of how it works today from Kusha and Ryan, but let's just start big picture first.

Yeah, I'd love to to kick it off and please correct me if I misspeak or say anything wrong. So just for a context for everybody on the call when and Ryan you'll actually probably know that Ryan you'll know this better than anyone so jump in. But when we decided Greenbox Capital decided to use Hubspot it was designed to be a temporary solution with the end goal being that we move into Salesforce as we redesign everything. As we've continue So with that, the connections the it was set up to be functional but not to consume too many resources. And over over time, that's that's caused problems. It's become more and more disjointed as we continue to use Hubspot and haven't done the migration and haven't fully invested resources into it. Um this year towards the the end of last year, this year, we're really relooking if there is even a need to move out of Hubspot or if we just want to go deeper into Hubspot and integrate. I think it's a fantastic tool. Um that opened up the discussion of what would it take to actually know if we want to use Hubspot, go deeper in it. And that's how we got to this point is we've hit this wall where we're we're cells is telling Ryan Goodwood, "Hey, this isn't usable. We're not getting what we need out of this tool. The data's wrong. It's stale. We don't It's inaccurate." Um that magnifies as we try and use the tool more um as we get into uh drip marketing, sequence emails, when there there's misplaced data, misplaced ownership. It just magnifies it. Um, Ryan's bend kind of had his hands tied uh is is my understanding of it which is I can only do so much with the data that that's being come that's coming through. And so the purpose of this meeting is to have uh the right people on the call that can actually have the conversation and we can start figuring out what does the lift actually look like to make Hub spot a usable tool. Um, That's that's what I'm hoping to take out of this. Do we want to invest tech resources into it? Is it minor? Is it major? What aren't we thinking about? And could this be the the future tool?

Sure.

Okay, and I have one context item and then one question item. Um, I'm sure Ryan wants to pipe in. So, one context item, this tech team here is not on the hook for configuring like hub spot. We are simply on the hook for getting the right data into hub spot and or out of hub spot. Just so everybody is aware of that. Um, That's really on Ryan and Chris. You guys are figuring out what good looks like in the system itself. Um so that's one context item. Okay.

Correct.

Um and then the question I have which hopefully will segue Ryan over to you is I heard you guys are doing some cool stuff to make some improvements in Hubspot itself. I know there was a gentleman named Rock and this incycle tool and lots of manual duping and all kinds of things happening in that world. Um In your kind of walk through of what you've got so far, can you kind of go through where it's at, where it's going? So we kind of understand where we fit into the workflow here at this point.

All right. So, I sent this around the other day just in case you guys actually have to look over it. Just basically kind of outlines the current state and kind of what a proposed like enhanced state might look like with, you know, kind of layering in some of these additional tools and like essentially upgrading the current hub spot or box hub spot sync or update service, I guess, as it's referred to. But in you can feel free to you know correct me. But so I think the current box update service was built probably five years ago. Probably back when that was you know still version one, version two of the HubSpot API which had a fraction of the features and capabilities that there's have today. It's also well before a lot of the other like enhancements just HubSpot as a as a system overall has been through over the last several years. But I think that, you know, it's kind of a Chris articulated and I've, you know, I've worked with, I think, five or six like sales heads at this point and so I've kind of like gotten the same feedback, you know, across, you know, different, um, leadership groups, you know, across, you know, a number of years. And it's not that that that the data is like bad coming in per se. I think it's just that the, um, there's, um, I think it just would be beneficial to have it updated more frequently, more real time in nature, um, because a lot of like sales type of workflows that are dependent on let's just say new deal closes and they want to you know something basic where it starts this journey of new deal closes email gets triggered to send the welcome thank you letter or whatever establishes the relationship with the funding advisor with the service team and then there's a whole cascading engagement campaign that kind of happens along the way as the as the loans are advances are paid down. And Those are all things that that are triggered on and that are dependent on the data coming in from the box related to submission balances, percent paid down and all the other like eligibility items. So once the historically what takes place is once a week Rock will do a export I think it's just a storage sequel query that exports to Excel. Essentially I think it could just from it's just from each of the three tables individually. Um, and I think that is just for the newly created records for that week. Um, and so the process has been he has to do this manual, I'll call it like export from the box, take that, do some formatting and some free formulations and some, you know, standardization, whatever. Um, and then five years ago was that we just used like the standard hubspot import tool which caused all kind of issues. And so then we built the incycle tools three three and a half years ago um which helped the process help to standardize the importing process and had a few like formulas that would help to make the associations using the box ID to link the submission to the contact to the to the merchant. Um and then create the records in Hubspot and then push the or I think Rock would manually send back the Hubspot record ID so they could get consumed into the box so that the box update service can use those just send the the updates that happen every 6 hours. So that's the, you know, high level kind of quick and dirty on it. Um and part of that process along the way has gotten more complicated because so for instance, when two records merge in Hubspot, they create a new record ID. And so if the box is using the Hubspot ID to then send to send updates to Merchant A, but that ID has changed because there was a a record merge, the box doesn't have that ID and so there's gaps there. Um So with the new with the new APIs like you don't have to feed back the hub spot ID to the other system. You just use that the one system we just use the box ID for all updates. So whether that's with the current update service where it just usually where we just use the box IDs to use the search API to go find the corresponding hub spot record and then update that or we do kind of what I'm in my mind proposing that we've done for others which is this like mirror sync, which is essentially like feeding the box updates into central database, same thing mirroring the hub data, do all of your like reconciliation there and then then push back into in the hub spot from there. So it's it's you know it's it's cleaned once and then it's in a good state. And then that way also any updates in hub spot get immediately pushed back so that reconciliation continues to take place. And then you can also have more frequent updates from the box. And then use that use the middleware to make any other updates as needed and handle all the all the in-between. Um, so then that ideally would be a situation where um in my mind it's a you know it's a it's an API endpoint that's into the box um that was pulled for you know uh contacts or submissions created since the last you know since the last fetch whether that's daily or every or periodically probably just like you know once a day would fetch to to to grab new records so grab new submissions grab new uh the associated merchants the associated broker the associated contact consume all those in, format them and then push them to the hub spot so that way you've got more real-time business intelligence that the sales team can act on. That's a lot of words, but that's the that's the high level.

So quick quick yeah so let me jump in real quick. Right now you're pushing data back to box how?

No. Right now, Rogue just sends a spreadsheet back to box

Okay, got it.

that has the hub record IDs for the records that he created.

Okay, and then Kushy you process that in somehow?

Yes, we manually import those in.

Okay, and and let me this picture doesn't show anything in your new scenario flowing back to box at all. You're just basically polling box to find out what data needs to be synced over to Hubspot and we if that's the case we no longer need Hubspot data back in box at all.

Yes. Correct. Unless you want it, but I mean there's no It's it's not that wouldn't be a requirement.

You know so Kushi that's that's the part I was most concerned with do we need anything back from Hubspot.

We do not. The only reason we require the hub spot IDs today is so that we can push that information to hub spot and we are actually using like the first version of the API. So that was the reason when they did not support custom IDs to be used and had to be hub spot IDs.

Got it.

Also, so today when rock does this import once a week, there's actually a Excel file that he gets the data in and he doesn't cycle and move all of that data into Hubspot and then provides us enough Excel back with the box ID and the Hubspot IDs. And then as long as we have the Hubspot ID in the box, that data is getting synced every 15 minutes daily. Any new data that gets entered into the box does not go into hub spot for at least about a week. Um, so that's what the delay there is. And what I was not aware about was that hub spot merges the records and creates a new hub spot ID. So, if that new hub spot ID has not been provided back to us, um and we have not been informed

That's what

that these were the two box IDs merged to this one, then we don't have that information in the box. And that could actually be the reason why a lot of these records might not be getting updated in hub spot.

Yeah. And that's and that's a obviously that's a very, you know, cumbersome process to have to like consume and and then update. So like for this example here, um this is for broker companies. Like there's there's four or five merged IDs HubSpot IDs, but all we really need is the is is the one unique ID from the box anyway. Um anyway, so that's yeah. And then

Kushi real quick. Sorry I just want to ask Kushi a question real quick on that. So the the frequency and this is maybe more of a business question but the frequency with which we we need these updates to go. Is it 15 minutes or is it 5 minutes? Um because if we're just looking at incremental stuff, then that incremental polling might not be too bad, but um is 15 minutes what the business needs or is 5 minutes what the business needs? Or is once an hour what the business needs? Do we know?

I saw again.

I can answer that, Brian. It's uh it depends on what the the lift is. It's close to real time is what we want to get to, but there's points of of diminishing return. So if going from 15 minutes to 10 minutes is a huge amount of effort. um then we'd we'd be okay with 15. So that's part of part of the scoping and and I'm unsure of what that work looks like.

I don't understand why it would be different. That's a setting, right? Pull every 15 minutes or pull every 10 minutes. I don't understand why with work would be different.

It's not.

Sure, I yeah I I don't know that it would as close to real time as we can get it is what the business needs.

Gotcha. So what we need to measure is the cycle time. Hey, we've done to pull and we've got so many records, here's how long it takes to process. And if that's 20 minutes, then we wait 30 minutes or if it's one minute, then we can pull as frequently as the business wants.

So what what is what what are the options on the box side as far as I think is it just can can there be like incremental property level like subscriptions also where it's like hey if just if version status changes then push that but I don't need all the other ones because I haven't changed. Or is it just the full record like for the full row from the table?

So, the way it works today is it's the full record that we're passing and the way we are passing it

Okay.

is we have a hub spot sync time and we have the last time that record was updated. So, every 15 minutes on the service runs we go and look at the merchant object like okay get us everything where the last update date is greater than the last hub spot sync time

Yeah.

But

So, so when you're when you're internal

and all of those records get first. Yeah.

Oh, so yeah, so you're when your internal last modified date and what, you know, is greater than the UPS about sync date or timestamp.

Yes. Yes.

Okay. And then and it it sends the full payload

It does, yes.

every time. Okay.

Uh, and when I say full payload, it's the specific properties that we're actually sinking into hubspot.

Yeah. Right. Right.

in your new your new model where you're pulling, you can pull to see, hey, were there any changes and then fetch just the changes that you need to to propagate, it sounds like. And and the the key point is if we can completely remove the load of Kusha to do the eventing on this, if you're going to be pulling then she shouldn't have to do any eventing whatsoever.

Yeah. Yeah, that's that's kind of my thought is it's it's just a you expose the API, we pull it, look for new records or change records and then there's a, you know, there's a payload Yes.

That makes sense. And then you were identifying like three Can we scroll back up just a little bit, please? I think you were identifying like three different uh things that might change. Who should you agree with what we would need to expose? Is it merchants? Is it merchant owners? What What all would we need to expose to them and do we have the last updated date timestamp stuff we need for those?

I'm assuming that the current objects remain the same, which is merchant owners and submissions.

Great. Does that sound right?

And we're

Yes. And then I think if there's a is there a new broker table or is it still

the same. There's not

brokers have its own they have they have their own table, right?

Yes.

In the database? Yeah. So ideally it's submissions, merchant, merchant owner, broker and then possibly users if you're going to be um So I think there's the desire to you know to manage the like renewal partners in the box and then we can bring that in I'm spot to make the changes. Is that a different table set?

Yes, so that would be a different table. Um, and there would be some logic associated to it. Um, and also when you're saying brokers, I'm assuming you'll need the brokers as well as the perhaps.

Yes, yes.

All right.

So the reps are living their own table also.

Yes.

Okay. Yep. The

If we if

Now, quite When you guys are looking at that, you tell us too whether you need to pull those things discreetly or if you want to go ahead and just pull them in aggregate. If there's a case for like the merchant owners, if we're grabbing the merchant owners, do we just feed all that into merchants or anyway, we can optimize however makes sense for you guys to pull and then feed hub spot.

And also there I think there's some more properties that we're sinking into hub spot which are in hub spot related to the object, but in the box it's a related property. So as an example the renewal eligibility date, right? So that's something which I believe is stored at the merchant level in hub spot, but for us that's not at the merchant level. That's associated to the fundings and then we have a logic

I've

submission deal.

that We have a logic that

So that's the other like benefit I think I think Kush is that you wouldn't need to like have that logic piece you could could just feed the raw and then we could have the middleware kind of run the logic itself instead of you know either way I mean either way it works in the same like if it helps to kind of take some of the lift off to you guys.

Yeah, no, having you guys pull exactly what you need. You know, you use your source tables for hey this table out of change now. I got to go fetch all this related stuff. Um, do it. The whole idea is to not have Kusha responsible for what needs to be synced.

Right. And that yeah, and I have to like make like logic changes on on y'all's side if if not necessary.

Sarah, did you want to jump

got a clue uh

in? You had your hand up before too. I know Chris

I did but Chris Chris can do real quick.

yeah I'm right right on the same topic just quick question. If the data is not to go into details because there's definitely data that we want in Hubspot that we don't have right now. If it's If it's in the box, am I correct in assuming that we can pull it into hub spot with an API if we want to? So it's just be a mapping what what we want to pull out of it.

Yeah. Well, it's never brings a good point is that

Okay.

to the extent that like the full schema would be available that way um you know you just you're that way like we can in the future if you say hey we want to like you know pull this in now that it wouldn't require like a re-engineering on the tech team side because they're just the full payload of all available

Yeah, no.

problems certain that or something like that.

No. No.

No.

No. We will expose very specific things only on an as needed basis.

Okay. Okay. Oh no, that's

Sorry, sir. I had to jump in on that one.

fine. Just

I I appreciate the thought. The path pattern can be used, but

I didn't

no, if we're going to do endpoints,

Okay.

they will expose only very specific things, they'll do it through API M. Um, and if there's any change to that, we also have to do the PII classification stuff as well, guys.

Oh,

Yep.

I'm aligned.

But my my point in asking though I think that's just a mapping exercise right? Like we could pull it all through and that's not saying we will won't.

Yes,

That's a discussion and we can figure it out and get it and and update it and keep

totally.

hygiene on it. That was that was the intent of the question. So perfect.

Now

100% Chris. Yeah, anything that it makes sense to sync over, we could expose

Thank you. Fantastic.

in those APIs and we can do them atomically or in aggregate whatever makes the most sense for you.

That's incredible. Okay.

I have a question about the renewal. Well, I actually have a few questions, but I'll start with the renewal date because you just mentioned that last. So it seems like there's some misunderstandings about what the source of truth is. is for that. I think what I'm hearing is that hub spot is the source of truth for that and you take that logic away from box and box doesn't have to really worry about that anymore. Is that right?

no box will remain the box of truth.

they're Yeah.

It's just that it'll get updated in Hubspot frequently enough to be accurate.

Okay, I misunderstood what Ryan was saying. Okay, thank you. That was question number one. And then the other question I had, it looks like your reconciliation thing here in the yellow. So you're you're basically going to automate everything that rock and in cycle and like all of that will be automated. So

Correct. Correct.

Okay.

Yes.

And that's the de-duping and the invalid email checks and all the things that you guys have.

Yes. The Yeah, the entire like processing layer would be done in one spot without any manual intervention.

And what is your timeline for building all of this?

And then uh depending I guess you know on on you guys but uh it's it's probably like a two-week project once it's started and then but we probably have to like you know do some scoping a little bit before that but Um, it should be pretty straightforward though. Just depending on how many endpoints we're we're polling from. But I think on your on your guys side on the tech side if you know if you could kind of start on like what the framework and the shape of it might look like and then I can start on my end so we can at least get some um yeah the beginning part started but otherwise it should be pretty pretty quick and easy to to get done.

Sir, obviously going to want to understand what tech tech stack these guys are going to be using. Um, so do you want to take a moment to talk about that now or do defer that?

No, let's let's do it. We're here. Do

So, what are you guys building this on?

So we we're we're going to build it on Firebase which is uh you know the front end of the player for Google Cloud. So it's a FireStore database and Firebase and then Firebase functions to do the processing.

Okay, he's in a uh multi-tenant environment, a dedicated environment, we own the Google account, you own the Google account.

Uh either way but you know we the way it would be right now is that it's it's our environment and then it's just a separate project just that's just for you guys and you can be admins on it also.

we phone it afterwards and are we build for the usage of it? Like how does that work?

Like no we would be we would we would own it we wouldn't pay for it. I mean it's like 50 bucks so it's not like it's you know a large load. Um, and then we would maintain it.

Okay.

But if you'd rather like set up your own Google Cloud account and add us to it that way and then set up a Firebase account, that we could do it that way too. It just would be, you know, obviously quicker and within our own environment.

I don't think we have the capacity to add another cloud environment. Would you be interested or open to exploring any other tech stack for this?

Uh, yes, it would just take longer.

Okay. I think that might be I don't know, Brian, maybe we can take it offline, but I feel like that would be a business discussion about our strategy for this long term, because the idea was to use Goodwood to sort of

Bridge of the app.

save us capacity and so that might just be the right approach, but we need to think about it.

Yeah. Yeah. Yeah, let's take this one more off. point. Kusha?

Um, just something on the lines I know Hubspot does have a connector with data bricks and we are using data bricks where our data is going to be so maybe that would be a preferable option.

Yeah,

Um, on our Yes, on our side we can take our design offline. I wasn't going to go into it today.

but you're right, Kusha. That is a potential candidate for it. But having these guys own the interface to hub spot and all of hub spots changes and things like that and you know it'll be a single service to just handle this for as long as we need it also might make some sense. And sir, I can think like you said, it really ties back to how long are we going to keep using hub spot from the business perspective. You know, we go in all in on it, we shift and off of it, we just keep in a steady state that I think should inform uh the solution. As far as implementing uh our side of it, um we would absolutely be able to implement um rest API endpoints that would hit the transactional data. Gosh, we could have it again make sure that it only hits the read replica. Um and that would be scoped specifically to the fields that you need, but that could change. We can have one or multiple endpoints. Um all of that would need to go through API So we use API M as our front end and then we could do all off based credentials with you give you some service principle credentials and basically you just authenticate to our API M and be able to make those calls on an as needed basis.

Perfect.

Chris, did that make sense?

And then that

Brian

Sorry, Chris did that make sense?

Not totally.

Okay.

That that that would be worried some if it did all make sense. I do think that that that's the right question though to take off offline. This is exactly it is. There's a there's a strong likelihood that we'll be using hubspot for marketing indefinitely and if there's a way to to use solid cells in hubspot and and make this work. It might be worth the investment now. Um either the way I think this exercise pulls us into either this is going to be a quick fix and we're going to go a different direction long-term or this is our our long-term solution, but we should be able to flush those out.

Okay. Gotcha. Ryan, did that make sense from a interface perspective?

Yes, sir. Perfect.

Sorry Kushal, go go, please.

Um, my only question was for the starting point, are we only going to be mapping the current fields that we have or are we also looking to add more?

Uh, that is a not me question at the moment. I know I know like a couple of I think that Jennifer had mentioned and then

Yeah.

We'll We'll need more fields. I I can tell you right now there's like that that'll be the exercise. We'll want to uh see see what it is and then have the discussion

Yeah.

Yeah.

like Brian call out of what we can, can't, send, want, and won't.

Do Do Yeah. Do Do it once, do it right. Absolutely.

Yeah, so just as I'm raise that next steps would be you guys are going to put together the requirements that you need and we can take offline and talk through this approach we want to take on our back end and then maybe regroup.

Sounds good.

Chris says that what's the sense of urgency on this one?

Um I've needed it since the day I started here a year and a half. Uh so and I see that like there's urgency to get this done and and move it forward. Um the sooner the the better. But I understand there's competing prioritize priorities and we're already a year and a half behind where I want to be on that. So, high sense of urgency, but um let's make sure it makes sense with what we're deprioritizing over it.

The nice thing is that

Well, actually I was just going to say I think the right answer is renewals is a huge part of our strategy and this is impacting our ability to do renewals effectively as such this is probably a high priority.

Let's I

And I was going to say, this is a fairly straightforward parallel type task with Brian doing, you know, the majority of the work and and handling that stuff inside. Um, Sarah, I could easily work with Nova and Het and we could uh get these endpoints exposed, no problem.

Awesome.

be awesome. Look at Chris's smile. You just made Chris's whole year, seriously.

know. You You all did.

Is

This is uh This is great.

Yeah, so Ryan really what we need is you and Kushi to put your heads together on what all the data is with Chris. Kushi as usual you would kind of dictate what the queries look like or the views look like and then we just drop a API fast API service in front of that and ensure that it's only hitting the read replicas and the way we go.

Yeah, thank you.

Sounds good.

there like a um to the extent that you can like a like a schema doc that you could share and then I can help just to kind of put together the mapping for everyone just so they can visualize what like what everything's mapped to you on both sides today and then that'll help I think maybe in point any gaps or anything.

So you just want me to provide the fields that we're sending over today.

And like tables and fields, yeah. Like if you have like this like a database schema or that something like that, I can

I think

just like use that as this use

That's That's

I think it would be better to do it the other way around where you provide us all the fields that you want in hub spot and then we provide you the mappings for it.

Yeah. Yeah. Yeah, yeah.

It's pretty large database. Lots of tables. It would be quite a bet to give you the schema and you would just your brain would break, I'm sure.

Okay.

We'll figure out how to map it for you and we'll use this consistent and standardized naming convention on the rest endpoints for you. Oh,

All right, let me see what I had. I think I had um Yeah, I do have the ones that we have currently. Let me just Do you guys have this by the way? I can if you don't I can resend it and then it's got like a mapping dock on it.

great. I'll defer to Kush on.

So it's

It was in in

This is just for the CSV though, so.

Yeah.

Is are these only field are you run are these fields from the file that rock uses?

This is correct. This is just the CSV map to the hub spot properties and I think I may have one for the update service but I can and show you that too.

All right, yeah because the update service

Just which ones are mapped.

yeah the update service will probably have more fields. That's why.

Okay. Um okay, perfect. Oh, the other thing is part of that, yeah, is that we'll end up creating like unique IDs for all the box IDs because back when it was originally created, that wasn't a thing. So, um we've done enough for a couple of them, but for every box ID will be a unique ID in Hubspot also, so that will avoid de-do like the duplicate problem in the

awesome.

I've also

once and for all.

part of our standard interfacing schema now includes a completely standardized way to identify any object, whether it's a merchant, an owner, a loan, whatever, as a string. So are you guys using string kind of keys for that or what does that look like?

Um yeah, so that'll be a a a string property and hub spot for the box IDs.

Perfect. Okay. Because what we're going to do is wrap those a little bit so that we're not using the raw box IDs. We'll want to use a cleaned up version so that it's the same thing that Salesforce is using and any of our downstream analytics might be using. Box one has a mix of integer keys and different kinds of keys. So we we proxy all keys with one standardized string format,

Okay.

that'll make it really easy for you. And And that's what we would expose in the APIs.

But are you saying that that that the ID itself is going to change from what it is today?

Um,

So like for instance, if I'm using like these IDs today

yeah.

for merchant ID, is it going to be a different unique ID?

Um, doesn't need to be. Doesn't need to be.

I

If that makes it easier not to be, that's fine.

mean Well, I could you know the other I was just going to suggest that like I can just you know we can just If you have a like way for me to map the old versus new, great. Well, that'll be a one time like you know change and then we can just use the new IDs going forward.

It It is. And actually, so those numbers actually always remain. It's just how they're prefixed that tells you exactly what that ID comes from. So So, it would be in this

Okay, so it's like cable and

case, yeah.

cable ID and record ID. Okay.

Yeah, yeah, yeah. So, I I will be real straightforward uh now.

Okay. Yeah, that's

And that number, that actual original ID from box does absolutely get preserved in the new record. It's just as prefixed for

Okay.

uh avoiding collisions. Does that make sense?

Totally, yeah. Yep.

Is there any data cleaning and cleansing that needs to happen on our end? And that might be something you want to think about and the requirements you pull together.

Yeah.

On the box side, you mean?

Yeah, because we will have we can do some of that in this project. process potentially if needed. I mean, we're leaving everything on your side, but if there's anything that you struggle with that you need on our side, just be thinking about that as well.

Yeah, kind of the

I think the only thing that

Sorry, go ahead.

Oh, so that the only thing that comes to mind is the um I think we use the I think it's the LU processing status which is the proximate for deal stage in hubspot. I know that those can like change over time as well as other like you know enumeration properties on your side. So just a way to like if there's a change then maybe just like a property schema push to so we can consume the update and replicate on the on the other side. So for instance like if you had ABCD right for your like pick list on the box but then you add a you know a fifth one There's just, you know, there's needs to be a way that we can

Okay.

that the system can be aware of that so it doesn't like crash. Without anyone knowing, you know,

No.

which is has happened in the past.

Um, Ryan question on that.

There

Does hub spot still for like these pick list still like rely on the text value? All

can be with a label and an internal value for it.

right, so basically like if today we were to create a list with ABCD, the internal value would be ABCD. It doesn't It doesn't use like a integer unique value, right? Or an ID. Okay, because that's the issues that we run into some sometimes when we create a use reason on our end and let's say it's small a b c d and then we change it to capital a and then b c d. It's technically the same reason for us but in Hubspot it says that the reason no longer exists.

Yes, so I think what you were saying, so like it's the API is going to use the internal name.

Yeah.

So you're saying if you added if you added another one but it was like lowercase t, that would fail.

Yeah.

But that mean that could be, you know, that's it's fine as long as like we're But if also you're saying that like these two things are actually the same, that's It's fine too, we just had that like in the logic in the in the middle where. But like right now like if you're just doing direct API like without any like you know transformation logic then it's you know criminal history lower case is not the same thing as this.

Got it.

Well, so there's a couple of approaches that one we simply pass the new values and it's your job to figure that stuff out and add them to the delta to

Right.

hub spot or we give you query ability against our lookup tables and again you're querying those first updating any lookups and then fetching the correct values. That's how we cascade stuff to Salesforce for instance. We take all the lookups cast them for a push, push the new lookups up to sales force and then when the imports occur those values match an appropriate look up.

Yeah. Yeah, that's perfect.

So again

So that and that's in in

I would go ahead.

the use case for that is for this for the same kind of thing where you there's different enumerations for a property value or something like that.

Exactly, yeah. So what we could do

Okay, sure.

is again expose an endpoint which is hey here's all of our lookups you look through them and see if anything's changed or we could do them individually. And then you make sure that you query that before you push any updates to Hubspot.

Yeah. Okay.

Because I don't want Kusha responsible for that or a human in the middle on that.

Yeah.

Thanks, Brian.

Kusha, does that dive for you? You

Yes.

Yeah, definitely for like the processing status stuff because it's Yeah, that'd be great.

Yeah, I think it would not only for that it will be for decline the activation reasons and then also like our employee list and

Yeah.

the AM and Ram list because those keep changing.

Okay, great.

guys just need to pin down which of those are lookups and we can expose a lookups thing that you can either check all of them or individually, we'll make it parameterizable. Um, and process wise you update look ups then you update data. Kusha, I assume that the chance of us updating a a tag and using it between them doing that is nominal in our scenario?

When you sit I give me like the decline reasons and such

Yeah. Yeah.

that all depends on business.

Well, but so if if if the business says, "Hey, I want a new tag." You're not going to put that in place immediately in the data to base and start using it without a release or something, right?

Not run necessary because our admin users actually have the ability to add new decline reasons

Okay.

because there's no other functionality in the back end that those decline reasons need to be associated to certain actions

Okay.

since the users are the one who selected. So yeah,

Okay. Okay.

but today

There is There is a possibility.

yeah, there is a possibility and in the current scenario to avoid hub spot missing those there's actually a process in place Whenever business adds a reason, they need to all send out an email to Ryan letting them know a new reason has been added.

Okay. Um,

Yeah, I just I think I like his idea of being able to just pull for new new you know new pick list items.

yeah.

That way it's you know.

Yep.

Yes.

So, if So, if we use that approach, hey, we first we do lookups and any updates we push, then we fetch all of our data and push the new data which um typically would only include uh those those values, but there is a slim chance that we could have a new value that doesn't populate. It would just be, okay, catch that error for that record, right? Recognize that that's what happened, repopulate the the lookups and then retry that record. Or catch it in the next time, right? Because great, that one didn't update this cycle, the next cycle updates will be there and it would push anyway.

Right. Yeah.

So you guys just call me.

Yeah, in my mind it's Yeah, in my mind it's almost

Yeah. Yeah.

like it's just it's just like like another secondary sink between the picklist tables on both sides.

Perfect.

Awesome.

Awesome. Good. Um, I don't want to have any more questions. Does anybody else?

Do we have time frames? Uh maybe I missed it, but um like around the action items, Ryan, you're going to come back with uh did did we assign time frames on that when to expect things back by?

I'll get the I think I was just going to send you back the the current hub spot box uh you know mapping and then I'll just throw it in the same report so it's there for everybody. Um unless there's something else that you needed for me. I'll get that to you tomorrow that works.

Yeah, sounds fast.

And then, uh, Chris, on our side realistically, um, we'll just need to I can just tell by the conversation we already directionally know what we need to achieve. We just need to see how it slots in and we'd have to kind of size the work and give you back some dates on timing.

Perfect. Okay. Let me know. Let me know how I can help Sarah offline.

I think your only your biggest competition is model two. Um, which might put you in the queue like at the end of the month likely. Um, but I I think that's where your business value conversation comes into play and if we would want to pivot one thing for another.

Yep, definitely.

Okay.

Okay. Good discussion.

All right everybody.

I didn't realize we were on the critical path to your success. So, I'm glad we met and happy to get you continue

Like wise. All right, guys. Well, I appreciate your time

Thanks all.

and we'll talk to you soon.

All right. See you.

Thank you.

Bye, guys.

See you.

Good seeing you, Kishan.

Thank you. Bye.

Bye.