Pipeline Tab API Integration - Hubspot

[RichardJamesLopez]

Creating a Hubspot API for REST access to Ourmada

• [x] Create a Private App on codypomeray01@gmail.com 's Hubspot account

• [x] Meant to have Read access to CRM->Deals table

• [x] Retrieved App Token from Hubspot app

• [x] Added Token value to Vercel Env variables titled HUBSPOT_TOKEN_1

• [ ] Create a file in latest code w/ a page view of Hubspot data

[RichardJamesLopez]

@nmwur I now have a separate API for hubspot data.

How would you advise we surface this data in the current app? Should it be a separate tab item, or a different type of pipeline available to the user?

If we create a skeleton page with the proper UI/UX, I can attempt to feed Hubspot data into a table in a similar way we do Notion data.

[nmwur]

should there be only one api integration per organization (hubspot/notion/etc)? if so, i think we could just surface the pipeline type in the Custom rules page in Settings (#19).

otherwise, we could still try to encapsulate data source selection logic in Settings by having multiple Custom rules tabs, each per source, and enabling admins to converge multiple data sources into one table for members to see in the Pipeline page.

am i on the right track?

[RichardJamesLopez]

What is the difference of effort it would take to do this:

otherwise, we could still try to encapsulate data source selection logic in Settings by having multiple Custom rules tabs, each per source, and enabling admins to converge multiple data sources into one table for members to see in the Pipeline page.

vs

should there be only one api integration per organization (hubspot/notion/etc)? if so, i think we could just surface the pipeline type in the Custom rules page in Settings

The former seems like the more elegant solution, but let's scope out how different these solutions are first.

[nmwur]

agree, also the former solution seems easier to manage since each Customer would have a unique set of fields from their data source anyway

some thoughts on the difference between these two solutions:		one API per Customer	multiple APIs per Customer
our efforts	manually setting column names in database on: - Customer onboarding - Customer changing a column name in their data source	adding: - column mapping ui - respective database tables

here is a rough mockup of how the column mapping ui for admins could look like. i'd like to learn more how this aligns with the Custom rules functionality (#19)

[RichardJamesLopez]

Re: Mockup - I think it looks quite good. I made 2 comments in this version:

Re:

i'd like to learn more how this aligns with the Custom rules functionality (https://github.com/RichardJamesLopez/app-nesting/issues/19)i'd like to learn more how this aligns with the Custom rules functionality (https://github.com/RichardJamesLopez/app-nesting/issues/19)

API integration (and maintinance) and Custom Rules Issue 19 go hand in hand. I actually think after the initial setup they should probably be on the same page (they should align quite perfectly and is convenient to the admin to adjust everything on the same page)

However, for the initial setup I am open to hearing your thoughts on how it would be to execute. I see the pro of having everything on 1 page as being convenience, and only a single page to maintain. The con is that the business logic can get overly complex.

[RichardJamesLopez]

Update on my end:

• added new files for DealRouter_Hubspot.ts and hubspot.ts on local machine.
• Updated package.json and env.js to install https://www.npmjs.com/package/@hubspot/api-client

Still to do:

• add log messages to see if current HubspotActivity is flowing through

[nmwur]

API integration (and maintinance) and Custom Rules Issue 19 go hand in hand. I actually think after the initial setup they should probably be on the same page (they should align quite perfectly and is convenient to the admin to adjust everything on the same page)

i see! and since there is no need for hardcoded "Ourmada columns" as the single point of integration across the APIs, maybe we could even prepend this mocked ui or Custom Rules to the Pipeline page as a toggle-open panel for admins. i'll also think about the initial setup flow

[RichardJamesLopez]

@nmwur Can I reassign this task formally to you?

I can send you the files that I worked on, and we can keep the comment history for posterity's sake.

[nmwur]

@RichardJamesLopez yes, on it

[RichardJamesLopez]

FYI @nmwur - Added a new column for "Visibility" which is a property under the deal information card of a deal.

Right now, I have a single deal assigned to each of the following 3 values:

• Full Visibility
• Custom Visibility
• Hidden

The rest of the deals do not have a value assigned to them yet.

[nmwur]

update:

• the Pipeline page is under construction

question:

• i forgot, should there be a default "Visibility" value for null?

[RichardJamesLopez]

When we have the Visibility Default option, then all null values should be that selection option. @nmwur

Until then, I am fine w/ Null. (for this particular db, I'll make sure to go through each one and select a visibility setting.

[nmwur]

todo:

• [x] populate individual deal's page
• [x] apply visibility to Pipeline based on api
• [x] store system fields (e.g. value, status)
• [x] add "deal owner" column