Solar Customer Portals: Connect HubSpot Milestones With Supabase Customer Access

What this looks like in solar installation and O&M services

An installer provides a portal for commercial customers tracking several rooftop projects. HubSpot holds relationship and project communication fields; Supabase serves the portal. One customer user manages all locations while another handles a single building. A projected installation window changes, and the account team needs to update the portal without implying that a final schedule was confirmed. Customer access and milestone meaning are equally important to making the shared data useful.

Records, ownership, and update rules

Work through the process

1. 01
   Define customer-facing milestones

   Select the events that help the customer understand progress and required actions. Give each a plain-language meaning and distinguish planned, awaiting evidence and confirmed states. Avoid exposing internal workflow labels that customers could interpret as a promise or formal approval.
2. 02
   Map project identity and relationships

   Use stable project and site keys to join HubSpot context to portal rows. A company can have multiple installations with different contacts and dates. Keep those relationships explicit so a change to one project does not update every project owned by the same customer.
3. 03
   Separate forecasts from confirmed events

   Store the estimated date and actual verified event in distinct fields. Include the update time and relevant customer action. A schedule forecast should not become a completed milestone simply because its date has passed; the owning operational record must supply the confirmation.
4. 04
   Enforce portal access

   Use Supabase grants and row policies for the approved project memberships, and test both allowed and denied access. Keep connection secrets server-side. Syncing the right milestone into a table is insufficient if a user can query another customer's rows or documents.
5. 05
   Handle customer submissions as requests

   If the customer updates an access contact, uploads a document or asks to change a date, record that action with its source and time. Route it to the responsible team before changing finance-owned or operations-owned fields. Return a clear received or confirmed state so the customer knows whether the request has been accepted.
6. 06
   Keep uploaded evidence separate from its acceptance

   A customer uploading a required document establishes receipt of a file, not that the document is complete or accepted by the project team. Show received, under review and accepted states where useful. If a reviewer rejects it, provide the specific missing information through the approved customer-facing message. This gives the portal a clear feedback loop without letting file presence alone advance a milestone that depends on a substantive decision.

Handle the exceptions explicitly

User belongs to several project teams

Grant explicit memberships and show only the approved scope for each role.

Forecast date passes without confirmation

Keep the milestone unconfirmed and route the stale forecast to its owner.

Customer requests a schedule change

Store the request separately until operations confirms the revised commitment.

What to verify before expanding

• Forecasts and completed milestones are visibly different.
• A user cannot read another customer's projects.
• Customer requests do not overwrite confirmed operational state.
• Every published milestone includes the correct project and update time.

Technical references

• Stacksync HubSpot connector and object support
• Stacksync Supabase connection setup
• Supabase row level security