Portal Mirror Architecture — Advanced Reference
This page is for administrators, technical RevOps teams, and security reviewers who need to understand how Daeda AI prepares connected HubSpot data. Normal users can start with Querying HubSpot.
Portal Mirror
Section titled “Portal Mirror”A portal mirror is the controlled, queryable copy of HubSpot data selected during portal connection. It gives Daeda AI enough structured context to answer large questions efficiently while allowing administrators to limit what is included.
The mirror configuration records the selected data categories and any filters applied to records, properties, workflows, or other supported data.
Large HubSpot Objects
Section titled “Large HubSpot Objects”Common CRM objects such as contacts, companies, deals, and tickets can contain large numbers of records. Daeda AI prepares these in bulk using HubSpot exports or the appropriate HubSpot API, then loads them into the secured portal mirror.
These larger snapshots are refreshed on a scheduled basis. More recent record changes can be synchronized between full refreshes.
Smaller Configuration Areas
Section titled “Smaller Configuration Areas”Smaller HubSpot areas such as forms, workflows, lists, pipelines, users, and portal configuration can normally be refreshed more quickly.
Daeda AI groups these sources by how they are retrieved:
- HubSpot sources use supported HubSpot APIs.
- Bridge sources use the optional Daeda Bridge and an active HubSpot browser session.
If the Bridge is not connected, Bridge-only sources are skipped rather than fetched through an alternative route.
Refresh Behaviour
Section titled “Refresh Behaviour”Daeda AI keeps actively used portals refreshed automatically. An AI app can also request a refresh when a question needs newer information.
Refreshable areas include:
- CRM changes since the latest full snapshot
- API-backed configuration areas
- Bridge-backed configuration areas when the Bridge is connected
Large CRM snapshots are rebuilt on their scheduled cycle rather than fully regenerated for every question.
On-Demand Data
Section titled “On-Demand Data”Some information is too large or too rarely needed to keep fully prepared at all times. Daeda AI can retrieve this information after the relevant IDs are known.
Current examples include:
- List memberships
- Property history
The technical hosted MCP tool for this is fetch_on_demand. Normal users should describe the business question and allow the AI app to choose it when appropriate.
Readiness States
Section titled “Readiness States”| State | Meaning |
|---|---|
| BUILDING | Daeda AI is preparing or refreshing the selected data. |
| READY | The selected data is ready for normal questions and planning. |
| PARTIAL | Some data is available, but gaps remain. |
| FAILED | The latest preparation did not complete successfully. |
| IDLE | No preparation job is currently running. |
Wait for READY before relying on investigations that require broad portal context. If a portal remains FAILED, review its connection and mirror configuration or contact support.