Data Archiving for Salesforce

Deployment model

Configure a defined record scope in Salesforce, run the archive workflow on your Linux host, and retain the resulting data in the selected database.

• Make record selection explicit: object or table, fields, date and status filters, related records, and attachments. Keep exclusions in the same configuration record.
• Review retained-data access separately from source sharing and field permissions. Define who can browse, export, or use archived data through an agent.
• Treat source cleanup as a separate approved operation. Validate the retained copy, dependencies, retention requirements, and recovery procedure before authorizing deletion.

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.

• 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.

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+10

Prepare 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.

cat /etc/os-release
uname -m
df -h
systemctl list-units --all --type=service 'vivly*'

Prepare SQL Server

Agree the SQL Server instance, database, schema, and connection identity with the database owner.

SELECT DB_NAME() AS database_name,
       ORIGINAL_LOGIN() AS login_name,
       USER_NAME() AS database_user,
       SERVERPROPERTY('ProductVersion') AS server_version;

Configure 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.

Pilot: retrieve a closed case with its context

Choose a small, explicitly approved set of closed cases. Record their IDs, account relationships, required activity, and files before capture. Keep active cases and held records outside the selection.

• Preview the policy and reconcile its selected IDs with the agreed sample.
• Run capture, then compare the retained fields, parent relationships, and files with the source.
• Ask an archive user to find a known case and open its required context through the intended viewer.
• Test an archive user who must not see this history, using the archive's own access policy.

Validate before expanding

• The selection rule includes the intended records and excludes held or active records.
• Source identifiers and required relationships can be traced in the retained data.
• A business user can retrieve an agreed historical case using the intended access path.
• Retention, source cleanup, and recovery responsibilities have named owners.

Everyday operations

Troubleshooting

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.

• Salesforce: describe objects, fields, and relationships
• Salesforce: query results and pagination
• Microsoft: ODBC encryption and connection settings