Record page integration without workflow disruption
The Tourvia component can be placed directly on Account, Lead, or Opportunity pages. The map centers automatically on the current record geolocation and loads nearby records, so reps get a contextual geographic view directly from the record they are already using.
That means the user does not need to leave the record workflow just to understand geographic context or nearby accounts.
Two layers of configuration, no code required
Admins can configure Tourvia in two separate ways:
- Behavior layer through Custom Metadata: features on/off, filters, defaults, and functional settings
- Presentation layer through Lightning App Builder: legend, colors, placement, and popup field visibility
This makes the product flexible without turning every change into a custom development project.
Managed package, then adaptable where the team already operates
The package installs cleanly, then admins can adapt pages, layouts, and reporting surfaces to match the reality of the org instead of forcing teams into a disconnected tool.
Tourvia is exposed for Account, Lead, and Opportunity record pages, and can also be placed on Lightning App Pages, Home Pages, Tabs, the Utility Bar, and Experience Cloud pages.
Why this matters commercially
For Salesforce admins and business stakeholders, this flexibility changes the buying story. Tourvia is not only a route planning product. It is a native operational component that can adapt to the real structure of the org.
That makes the product easier to pilot, easier to justify, easier to roll out, and easier to expand once the first workflow is proven.
Where Tourvia fits in your Salesforce page layouts
Because Tourvia ships as a Lightning Web Component, Salesforce admins can place it anywhere Lightning App Builder accepts a component. Each placement opens a different use case.
No-code configuration for admins
Admins configure Tourvia entirely through standard Salesforce tooling. No custom code is required at any stage of the setup.
The Lightning App Builder handles all presentation decisions: where the component appears, which record types see it, and which page layout it belongs to. Admins drag the Tourvia component onto any supported surface and assign it through standard assignment rules.
Functional behavior is controlled through Custom Metadata Types, which are accessible in Setup. Admins set component properties declaratively: default filters (account type, owner, territory), map style, visible object types (accounts, leads, opportunities), and display options. These settings live in org metadata and are version-controlled like any other Salesforce configuration.
Permission Sets control which profiles and users access Tourvia features. Standard Salesforce permission assignment applies: no separate user management system, no Tourvia-specific admin panel.
The result is a setup that Salesforce admins handle without involving a developer, and that fits naturally into existing org governance processes.
How Tourvia uses Salesforce platform features
Tourvia is built on standard Salesforce platform capabilities. This is what makes it genuinely native rather than just installable inside the org.
- SOQL for data queries: account, lead, and opportunity records are retrieved through standard SOQL queries. The component respects sharing rules, field-level security, and record visibility set in your org. No data is extracted or replicated to an external database.
- Lightning Data Service: record context (such as the current account address on a record page) is accessed through Lightning Data Service, the standard mechanism for reading and writing Salesforce records from Lightning components.
- Custom Metadata Types: configuration lives in metadata, not hardcoded component properties. This means admins can change behavior without touching the component itself, and settings travel correctly between sandboxes and production through standard deployment tooling.
- Permission Sets: feature access is governed by Permission Sets, which integrate with standard Salesforce user management. Adding or removing Tourvia access for a user follows the same process as any other permission change in the org.
- Platform Events: real-time updates within the component use Salesforce Platform Events where applicable, keeping event-driven communication on-platform rather than through external webhooks or polling mechanisms.
The practical effect: Tourvia inherits the security, scalability, and governance of the Salesforce platform by design, not by workaround.
Comparison: native integration vs connected apps
Field teams often evaluate Tourvia against external route planning tools that connect to Salesforce through an API or middleware layer. The architectural difference has real operational consequences.
| Dimension | Tourvia (native LWC) | Connected external app |
|---|---|---|
| Data location | CRM data stays in Salesforce | Data synced to external system |
| Login | Single Salesforce login | Separate login for external tool |
| Data freshness | Real-time from Salesforce | Delayed by sync schedule |
| Security model | Inherits Salesforce sharing rules and FLS | Separate permission system to maintain |
| Admin tooling | Lightning App Builder and Setup | Separate admin interface outside Salesforce |
| User adoption friction | Low: same UI, same workflow | Higher: context switch to separate tool |
Connected apps are not always a bad choice. When teams need deep integrations with non-Salesforce systems or operate across multiple CRMs, a middleware approach may make sense. But for orgs where Salesforce is the primary system of record for field teams, native integration reduces complexity at every layer: data, security, UX, and admin.
Frequently asked questions about Tourvia native integration
No. Tourvia installs as a managed package from AppExchange and is configured entirely through Lightning App Builder and Custom Metadata Types. No Apex development is required for installation, configuration, or ongoing administration.
Tourvia is natively exposed for Account, Lead, and Opportunity record pages. It can also be placed on Lightning App Pages, Home Pages, Tabs, the Utility Bar, and Experience Cloud pages. Placement on fully custom objects depends on your configuration and the address field structure available.
Yes. Because Tourvia queries data through standard SOQL and uses Lightning Data Service, it operates within the org's sharing rules and field-level security settings. Users only see records they have access to in Salesforce, with no workaround or bypass.
Yes. Tourvia can be installed and tested in sandbox environments before deploying to production. Configuration through Custom Metadata Types can be moved between environments using standard Salesforce deployment tools including change sets and the Salesforce CLI.
Tourvia is tested against Salesforce releases as part of the managed package maintenance included in the subscription. Compatibility updates are delivered through the managed package channel, not through manual re-deployments by your team.
Explore Tourvia native integration inside Salesforce
Install the free app on AppExchange, then see how Tourvia can be placed and adapted where your team actually works.
Install from AppExchange See use cases