Record page integration without workflow disruption
The Tourvia component can be placed directly on Account, Lead, Opportunity, or Campaign pages. On Account, Lead, and 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. On Campaign pages, Tourvia can display the campaign's members on the map.
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, Opportunity, and Campaign record pages, and can also be placed on Lightning App Pages, Home Pages, Tabs, the Utility Bar, and Experience Cloud pages.
Adapt Tourvia to the way your org already works
Salesforce admins can place Tourvia on the relevant Lightning pages, use the supplied Permission Set Groups, and connect route planning with existing Flows and record processes.
Teams can validate the configuration during the 30-day trial before enabling it for more users.
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.
- Salesforce data access: account, lead, and opportunity records are retrieved under Salesforce sharing rules, field-level security, and record visibility. Only the route inputs described in the DPA are processed by the Tourvia routing service.
- 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 and Permission Set Groups: Tourvia ships managed access for users, managers, and admins. Assign the supplied Permission Set Group for each role.
- 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.
Tourvia uses Salesforce sharing rules, field-level security, Permission Sets and Permission Set Groups, so the customer's existing governance model continues to apply.
Comparison: native integration vs connected apps
Compare Tourvia with external route planning tools by record storage, external processing, synchronization, access controls, reporting, and support ownership.
| 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
Request a 30-day trial via the contact form, then see how Tourvia can be placed and adapted where your team actually works.
Request trial See use cases