The NAVI AI Enablement Journey · Guide 06
Connections and Integrations
Bring your existing business tools and context to NAVI so people can accomplish more with AI.
Existing systems and dataCurrent business contextCustom connectionsApproved connection catalog
Core idea
Connections make your existing business information, data, and applications available through NAVI—so people can use AI with relevant context across the organization and accomplish more with the systems they already have.
Where this guide fits: Guide 02 identifies priority workflows and Guide 05 establishes access and authority. Guide 06 determines how approved systems, applications, and data support the work; Guide 08 brings those connections into a complete operating workflow.
Start with
purpose
Begin with what you want to accomplish and how the connection could help.
01Choose an objectiveIdentify the result, improvement, or new capability you want to pursue.
02Consider the information or actionWhat should NAVI retrieve, understand, create, deliver, or change?
03Try the simplest workable methodUse files, synchronization, live access, or controlled action at the level that fits.
04Learn and expandCheck access and results, then deepen the connection when doing so improves the work.
Be wary of connecting everything at once. If no one can explain what they hope to accomplish or learn, the connection may be premature. Start somewhere useful and expand from there.
Connection
levels
Choose the simplest level that can accomplish the goal. Move directly to live access or controlled write-back when the use case and controls justify it.
Files and exportsBounded documents, reports, or datasets supplied to the workflow.
Useful whenPeriodic refresh is acceptable and the team wants an understandable starting set.
Watch forStale snapshots, incomplete extracts, and manual refresh effort.
Curated synchronizationApproved folders or repositories synchronized into governed knowledge.
Useful whenMaintained documents should stay available without repeated uploads.
Watch forIncluded paths, duplicate versions, removals, and delay before changes appear.
Read-only system accessCurrent permitted records retrieved without changing the source.
Useful whenLive context matters and exports create delay or error.
Watch forRecord scope, paging, completeness, permissions, and availability limits.
Controlled write-backSpecific approved records or fields created or changed.
Useful whenA proven workflow can remove a defined handoff and the action is reversible or recoverable.
Watch forWrong targets, duplicates, retries, conflicting updates, and unclear approval.
Connection options are organization-specific. Access may use an individual account, a shared service account, a selected synchronized area, or another approved model. NAVI administrators can offer users a catalog of approved connections, while standard connections, custom APIs, and approved connections using Model Context Protocol (MCP) can support additional systems. GrowthIQ helps determine the appropriate approach based on the organization, provider, licensing, credentials, permissions, and intended use.
Information
movement
Consider what NAVI needs from connected systems and what it should produce, deliver, or change in return.
What flows into NAVIRetrieval and context
Records and fieldsWhich exact accounts, projects, tickets, dates, statuses, or other fields are required?
Documents and rulesWhich approved procedures, definitions, and templates guide interpretation?
Scope and freshnessWhich business unit, customer, date range, or event is included, and how current must it be?
EvidenceWhich source identifier, timestamp, or link must remain visible for verification?
What NAVI produces or changesDrafts, delivery, and change
Working outputShould the workflow create a report, dataset, message, or proposed record first?
Approved destinationWho receives the result, where is it saved, and which version becomes official?
Permitted actionWhich exact record, field, or status may be created or changed?
ConfirmationWhat success response or change record must remain after the action?
Why this helps: considering inputs and outputs makes it easier to provide enough context, avoid unnecessary access, keep information current, choose the right destination, and verify that the connection produced a useful result.
Let business systems remain the record keepers
CRM, ERP, HR, project, and other operational systems should generally continue to own their underlying records and databases. NAVI serves as an intelligence layer: it retrieves permitted context, combines it with approved knowledge, and helps people understand and use information across systems. When needed, it can send back specific authorized updates without becoming a competing copy of the source system.
Ownership and
readiness
Identify the responsibilities and prerequisites that keep the connection useful and operable.
Connection prerequisites
Resolve the items the connection will depend on.
Access and governanceDecide which users, records, folders, and actions are allowed before making the connection broadly available.
Connection requirementsConfirm the needed credentials, authentication, licensing, provider support, and other technical requirements.
Source readinessConfirm that the information is accurate, complete, consistent, and organized well enough to support the intended use.
Known examplesUse representative, trustworthy records and users with different permissions to confirm that the connection behaves as expected.
Operating responsibility
Be clear about who handles common connection needs.
Source quality and outagesWho handles data quality, system availability, and changes in the source application?
Credentials and authorizationWho renews, rotates, or reauthorizes access when it expires or fails?
Scope and action changesWho obtains governance approval before expanding users, information, or write authority?
Implementation and supportWho handles connection configuration, platform issues, and escalation to GrowthIQ or the provider?
A connection does not repair the source. If records are inaccurate, incomplete, duplicated, inconsistent, or poorly maintained, clean the source or narrow the initial scope before relying on it. Better access to bad information still produces bad results.
Business ownerPurpose
Owns the intended value. Defines why the connection exists, which uses or results it should support, and whether it improves the work.
Source-system ownerApplication
Owns the application boundary. Approves access and addresses provider changes, availability, and upstream issues.
Data or content ownerInformation
Owns the information boundary. Confirms meaning, quality, restrictions, and appropriate sources.
Connection administratorConfiguration
Owns setup and operation. Configures approved access, credentials, mappings, and testing, and coordinates technical support.
These are responsibilities, not necessarily four different people. One person may hold several roles, while a larger organization may divide them across teams. Business approval also does not automatically grant source access, credentials, or permission to change a system.
Read versus
write
Treat retrieval, drafting, and system change as separate permissions.
Retrieve
Read approved records or content without modifying the source. Confirm the user and record scope, and keep the source and freshness visible.
Starting default: read-only within approved permissions.
Create a working draft
Use connected information to create a report, message, analysis, or proposed record that remains separate from the official system until reviewed.
Starting default: working material until approved.
Change a system
Create, update, send, or otherwise cause an external effect. Limit the approved target and action, with confirmation for consequential changes.
Starting default: explicit approval and controlled testing.
Connection
verification
Test the connection within its intended use. A successful login or system response does not prove that the information, permissions, results, or failure behavior are reliable.
1Source accuracyRetrieved values match the authoritative application and retain necessary identifiers.
2PermissionsApproved users receive the right records and restricted users cannot reach excluded information or actions.
3Freshness and completenessLive, synchronized, or exported status is visible; paging, truncation, delay, and missing fields are understood.
4Expected resultKnown examples produce the intended analysis, draft, or supported system change.
5Failure behaviorExpired credentials, unavailable sources, missing records, and rejected writes lead to a safe response.
6Recovery and evidenceThe team can identify what ran, what changed, what failed, and who should correct or rerun it.
Do not convert “zero results” into a business fact until retrieval is confirmed complete. Missing, delayed, or permission-filtered data is not evidence that nothing exists.
Operate and
maintain
Keep the connection reliable as systems, access, information, and business needs change.
1MonitorFailures, authorization problems, unusual results, sync delay, and partial retrieval.
2MaintainCredentials, owner contacts, provider changes, field mappings, and included paths.
3ChangeRevisit the connection record when users, data, permissions, actions, or source behavior change.
4RetestRepeat representative results, permissions, and failure cases after material change.
5RetireDisable obsolete, duplicated, unsupported, unused, or unauthorized connections and dependent runs.
Optional connection
records
As connections become important, shared, or numerous, record the decisions people will need to operate and review them.
Document the connection
A concise connection record gives owners a shared reference for why the connection exists, what it may reach or change, how it operates, and when it should be reviewed. It may stand alone or be included within an existing capability or workflow record.
PurposeWhat work or possibility does the connection support?
OwnersWho owns the result, source, information, and operation?
Source and scopeWhat system, records, folders, or data are included?
Access and actionsWho may use it, and what may the connection read or change?
DependenciesCredentials, licensing, mappings, approvals, or support needs.
Review triggerA meaningful change, failure, or planned checkpoint.
Product behavior last reviewed August 4, 2026. Recheck this guide when available connection types, authentication models, permission behavior, provider support, or supported actions change.
This guide is a practical implementation framework, not a technical integration specification, security architecture, legal agreement, or compliance program. Connection availability and supported operations vary by deployment, provider, licensing, credentials, and approved scope.