AI Connectivity for Salesforce
Linux + MySQL
Connect an MCP client to a defined business dataset, configure the access boundary, and validate the resulting workflow.
What you will leave with
A tested, limited workflow with a clear identity boundary and an agreed process for reviewing agent access.
In this guide
Deployment model
Use this guide to configure the Linux host, data access, and operational controls for a Salesforce MCP workflow. Choose the data path before configuring storage.
- For live-source access, queries use the connected Salesforce account. Document its identity and effective access; do not assume that connecting an administrator automatically gives every client a separate permission boundary.
- For retained-data access, the selected database supplies the historical dataset. Configure and review that access separately from the source application's permissions.
- Record the MCP client, transport, endpoint or local process, authentication method, and allowed tools from your deployment configuration. Keep read and write authorization separate.
Use the installation package and version-specific configuration supplied for your deployment. This guide covers the source, host, database, and workflow decisions that remain consistent across package versions.
Before you begin
Bring the application owner, infrastructure owner, and data owner into the same deployment review. Agree the boundaries before configuring a connection.
Decisions to make together
- Which question or task should the agent be able to handle?
- Will it access current source records, retained data, or both?
- Which identity authorizes access, and which operations must remain unavailable?
- A named Salesforce administrator and an approved organization for the initial deployment.
- An inventory of standard and custom objects, relationship fields, and required files.
- A connection identity with the least access needed for the agreed task.
- An API usage budget and a plan for validating source automation during any write test.
Prepare Salesforce
Use a Salesforce sandbox or an approved test scope first. Inventory the objects, fields, and relationships that make up the business record.
Object visibility
Compare the connection account's visible objects and fields with the approved scope. Include custom objects and fields in the sample instead of validating only standard records.
Record relationships
Map parent and child records, reference identifiers, and files. For a recovery test, review required fields, validation rules, and automation that can affect inserted or updated records.
Inspect a small Salesforce record set
In an authenticated Salesforce REST client, use the API version supported by your org and deployment. Describe Case first to review the available fields and relationships, then send this bounded query. The paths below are source API requests, not Vivly endpoints.
HTTP
GET /services/data/vXX.X/sobjects/Case/describe/
GET /services/data/vXX.X/query/?q=SELECT+Id,CaseNumber,Status,AccountId,LastModifiedDate+FROM+Case+ORDER+BY+Id+LIMIT+10What to verify
Compare the returned IDs and fields with the same user's Salesforce view. For larger extracts, follow nextRecordsUrl until done is true; the first response is not necessarily the complete result. Describe output helps establish the field and relationship inventory, not a full backup of org metadata.
Salesforce: query results and paginationPrepare Linux
Prepare a Linux host with a dedicated application identity and an agreed operational model. Record the distribution and package version for your selected product.
Runtime and service account
Install the runtime required by the deployment package. Use an application account with scoped filesystem access and record who manages the service lifecycle.
Network and trust
Validate source and database routes, DNS, proxy settings, and certificate trust. Keep application access limited to the agreed network and avoid embedding credentials in scripts or shell history.
Persistent storage
Plan persistent locations for data and logs, with disk alerts and a recovery procedure. Check restart behavior and the handling of interrupted work before adding a schedule.
Check the Linux host
Run these read-only checks on the application host. Compare the distribution and architecture with the requirements for the supplied package, and identify the filesystem that holds persistent state.
Shell
cat /etc/os-release
uname -m
df -h
systemctl list-units --all --type=service 'vivly*'What to verify
Record the distribution, architecture, capacity, and installed service state. Native systemd packages need an operational service manager. An empty Vivly service list before installation is expected; after installation, reconcile it with the package's required units.
Prepare MySQL
Only apply this database checklist if your agreed MCP workflow uses retained data. Live source queries can have a different storage architecture.
Prepare a MySQL destination with a dedicated application database, a scoped connection identity, and an approved authentication method.
Compatibility and connection
Record the server version, driver, authentication plugin, and TLS configuration. Validate the connection from the application host using the connection identity that will run the workflow.
Types and encoding
Include non-ASCII text, nulls, precise numbers, long text, and date values in the validation dataset. Review character set, collation, and SQL mode when comparing source values with the stored result.
Capacity and ownership
Agree the account's schema privileges and the owner of database backups and maintenance. Measure storage growth during the first run and document restart and reconnect behavior.
Check the MySQL connection context
Run these read-only statements after selecting the intended database with the application identity. Inspect character encoding and SQL mode before comparing text and date values.
SQL
SELECT DATABASE() AS database_name,
CURRENT_USER() AS authenticated_account,
VERSION() AS server_version;
SELECT @@character_set_database, @@collation_database, @@sql_mode;
SHOW SESSION STATUS LIKE 'Ssl_cipher';What to verify
Confirm the database and authenticated account. A remote TLS connection should report a cipher. With the MySQL command-line client, --ssl-mode=VERIFY_IDENTITY and the appropriate CA verify the hostname as well as the certificate; a cipher by itself does not prove those checks ran.
MySQL: connection and TLS verification optionsConfigure the workflow
Start with a representative dataset, then expand the scope after validation. Use the connection settings established above and keep source changes behind the appropriate approval.
Choose one useful task
Start with an example such as preparing a case summary from approved records. Define the expected output and its source evidence. Keep the initial dataset small enough for a reviewer to check the result.
Specify the access boundary
Identify the source account, permitted records, fields, and operations. A connected service account is not proof of per-user permission inheritance. Document where user identity and authorization are checked.
Review the client and tools
Configure the MCP client with the transport, authentication method, and tool access defined for your deployment. Start with read-only access where available; review any write-capable tool separately before allowing it during validation.
Test the answer and its limits
Use known questions, missing-data cases, and requests outside the approved scope. Check the source evidence, freshness, denied-access behavior, and what the client retains or sends to its model provider.
Confirm the MCP connection contract
- For stdio, the client launches a local server process. Record the executable, arguments, working directory, and how credentials enter that process. A remote URL is not a substitute for a stdio command.
- For Streamable HTTP, record the supplied MCP endpoint, TLS and authentication settings, and the client's support for that transport. Confirm the client can complete initialization and discover tools.
- Review the actual tool list against the workflow's allowlist. Start with one bounded read, then test a denied operation and a connection failure. Do not assume the client supports every transport or protocol version.
Evaluation: brief a case using permitted live records
Choose one known case and a read policy that permits only the objects and fields needed for a briefing. Record the connected Salesforce identity and the expected source facts.
- Connect the approved MCP client and inspect the exposed tools before allowing a query.
- Ask for the case context and compare the returned IDs, source references, and facts with Salesforce.
- Ask for a field outside the read policy and verify that it is not returned.
- Ask the client to change the case status and confirm the read-only query workflow offers no mutation tool.
Scope of this example
Use the deployment's supported query tools. Raw SOQL examples in source diagnostics are for an administrator's REST client; they are not a model-controlled tool interface. Archive access requires a separate data path and policy.
Validate before expanding
- The agent returns an answer that can be checked against the approved source data.
- Out-of-scope requests do not expose restricted records or fields.
- The effective connection identity and authorization boundary are documented.
- Tool operations, client data handling, and review responsibilities are understood.
Keep a deployment record
Record the package version, environment, data scope, test date, expected result, actual result, and owner of each unresolved issue. Keep secrets and customer data out of shared support notes.
Everyday operations
After each run
Review completion status, record counts, failures, and source API usage. Resolve unexpected differences before allowing the next dependent action.
When credentials change
Update the connection through the approved secret process, verify a bounded read, and retest the required operations. Remove obsolete credentials.
When the source changes
Review added or changed objects, fields, access rules, and automation. Repeat representative data and permission checks before expanding the scope.
Before an upgrade
Record the current package and configuration, protect persistent data, and define the rollback procedure. Validate connectivity and a representative workflow after the change.
Troubleshooting
The client cannot connect
Check the confirmed endpoint, supported transport, network reachability, and authentication configuration. Do not substitute an unverified public endpoint.
The answer is incomplete or stale
Compare the permitted dataset, filters, source freshness, and any retained copy. Distinguish unavailable data from an incorrect model interpretation.
The agent can access more than intended
Disable the connection for the initial deployment and review the service account, tool scope, and authorization boundary before reconnecting.
MySQL values differ from the source
Compare encoding, collation, numeric and timestamp types, and SQL mode. Use a representative sample and inspect failed or truncated writes before expanding the dataset.
Technical references
Use these official references for the source APIs, database connection settings, and runtime behavior discussed above. They describe the underlying platforms; use your Vivly package documentation for its installation and supported configuration.
Review this deployment with Vivly
Bring your source scope, host, database, and success criteria. We will use them to identify the applicable package, open questions, and rollout sequence.
Book a demo