The CRM record is already the center of the moment
Opening another application is not the difficult part of a dealership workflow. The difficult part is repeating the lead search, locating the vehicle again, and deciding whether two tabs still refer to the same current record. Every reconstruction introduces a chance to select the wrong person, paste stale information, or abandon the small question that caused the employee to leave the CRM.
LotPro Companion takes a sidecar approach. On supported CRM pages, the lead remains open while a focused LotPro panel provides Workspace, Follow Up, Inventory, templates, calculator, and phone actions. Companion does not ask to replace the CRM or become a second customer database. Its job is to let a specific LotPro action begin from context the employee has already established.
An adapter should know less than the CRM
Each supported page has its own adapter because the visible structure, fields, and readiness signals can differ. The adapter identifies the current record and extracts only the values a selected action requires. A template may need a first name and vehicle description. A phone action needs a normalized number. Inventory may need a model or stock reference. None of those actions needs a wholesale copy of the CRM record.
Keeping the compatibility logic tied to the page that supplied it also makes failure more honest. If the page is not recognized or a required field cannot be resolved, Companion can withhold the action or ask the employee to confirm the context. Guessing from a nearby string would make the extension appear flexible while quietly increasing the chance of acting on the wrong lead.
- Recognize the supported page before reading context
- Select only the fields required for the current action
- Normalize values without recreating the source record
- Fail visibly when the adapter cannot verify context
Use the data without turning it into a new database
Companion’s CRM direction is ephemeral-first. Supported values are used to prepare the current action and are not automatically written into a parallel lead collection. Phone numbers can remain in memory long enough to start a supported call. Merge fields can be resolved for a draft without making the template itself customer-specific. CRM authorization tokens are never repurposed as LotPro credentials.
This boundary reduces both confusion and exposure. The CRM remains the source system for the lead, while LotPro owns the resulting task, template choice, calculator state, or inventory decision only where that product needs a durable record. If a future feature requires persistence, it must define tenant scope, purpose, retention, deletion, audit behavior, and the minimum fields before storing anything.
Iframe load was not a handshake
The side panel introduced a timing problem that was easy to dismiss as a visual glitch. A browser iframe can report that its document loaded before the LotPro application inside it is ready to accept lead context or appearance settings. Sending the payload at that moment sometimes lost the first update, leaving the employee with a panel that looked available but had no current record.
The host and panel now use an explicit readiness acknowledgement. The embedded application announces that its receiver is active; only then does the host send the current payload. The receiver checks the expected origin and source window, and the host targets the exact known origin instead of broadcasting. The same handshake can resend current state after a reload without trusting load timing.
Appearance belongs in the compatibility contract too
A sidecar can feel broken even when its data is correct if it ignores the surrounding CRM theme. Companion can deliver a narrow appearance payload alongside supported context, but the receiver must validate it, fail closed, and fall back to the saved or default LotPro skin when the host disables or omits an override.
The goal is visual continuity, not a claim that LotPro is part of the CRM. Dimensions, interactions, and product identity remain LotPro’s. The palette can reduce the seam between surfaces without allowing an arbitrary page to restyle or message the embedded application.
The result and the compatibility truth
On a supported page, the employee can keep the active lead visible, open the relevant LotPro tool, and begin with verified context rather than repeating the search. The value is a preserved decision thread: CRM for the lead, LotPro for the focused operation, and an explicit boundary between them.
DriveCentric currently has the broadest adapter coverage. AutoHub coverage is narrower, and recognized fields and actions vary by page. Page redesigns can require adapter updates. Compatibility names describe tested integration work and do not imply sponsorship, endorsement, data access agreements, or partnership. Preview onboarding must verify each intended page and action before the dealership relies on it.