Data Archiving for Salesforce
Windows + SQL Server
Configure an archive workflow that keeps historical records useful while separating retention from everyday operations.
What you will leave with
An agreed archive scope, a verified destination copy, and a retrieval test before any source cleanup is considered.
In this guide
Deployment model
Configure a defined record scope in Salesforce, run the archive workflow on your Windows 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.
Decisions to make together
- Which records are inactive, and what makes them eligible for archiving?
- Which related records and attachments must remain available together?
- Who sets retention periods, handles holds, and authorizes source deletion?
- 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 Windows
Prepare a Windows host whose ownership, service identity, and network routes are agreed with your infrastructure team.
Host and process ownership
Record the Windows release and deployment package version. Choose the account that will run the application, its file permissions, and the team responsible for restarts and upgrades.
Network and certificates
Review outbound access to the source and connectivity to the database, including proxy and certificate requirements. Limit any inbound application access to the approved network.
Storage and operations
Identify directories for application data and logs. Agree disk monitoring, credential rotation, restart checks, and the maintenance window before scheduling work.
Check the Windows host
Run these PowerShell checks on the application host. The service query shows installed Vivly services, if present. Compare the result with the service list supplied for your package.
PowerShell
Get-CimInstance Win32_OperatingSystem |
Select-Object Caption, OSArchitecture, Version
Get-Service | Where-Object DisplayName -Like '*Vivly*' |
Select-Object DisplayName, Status
Get-PSDrive -PSProvider FileSystem |
Select-Object Name, Used, FreeWhat to verify
Record the OS and available storage. After installation, required services should be running. Check both the service account's database access and its ability to read the configured certificates; success from an administrator's interactive session does not establish service access.
Install the Salesforce Archive Windows package
- Obtain the Windows installer and matching checksum for your database edition. Verify the downloaded file's SHA-256 against that release before running it with an administrator account.
- Use the SQL Server edition. Its one-click EXE includes the connector MSI and Microsoft ODBC Driver 18. Prepare the target database, login or approved Windows service identity, and certificate trust before the connection test.
- Complete the installed setup flow for the database and Salesforce connection. Test connectivity with the service identity, then check the installed Vivly services before creating the first policy.
- Record the installed version, configuration and data locations, license ownership, and recovery procedure. Use the package-specific upgrade instructions when replacing this installation.
Prepare SQL Server
Agree the SQL Server instance, database, schema, and connection identity with the database owner.
Connection contract
Enter the server address, instance or port, database name, authentication method, and certificate requirements. Install the database driver specified by your deployment package on the application host.
Schema and data handling
Use an isolated test database or schema. Test Unicode, long text, date precision, null values, and identifiers with representative source records. Agree how schema changes will be reviewed.
Database operations
Estimate storage and transaction-log growth from the initial dataset. Agree database backup, monitoring, and access review with the DBA; an application transfer is not a replacement for the database's own recovery plan.
Check the SQL Server connection context
Run this read-only query in the chosen database using the application's intended database identity. It checks the selected database and login without creating or changing tables.
SQL
SELECT DB_NAME() AS database_name,
ORIGINAL_LOGIN() AS login_name,
USER_NAME() AS database_user,
SERVERPROPERTY('ProductVersion') AS server_version;What to verify
The database and identity must match the deployment record. Verify schema privileges separately through the package's connection check. For ODBC connections, configure Encrypt=yes and TrustServerCertificate=no with a trusted server certificate; review driver and server compatibility before choosing strict mode.
Microsoft: ODBC encryption and connection settingsConfigure 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.
Create a policy
Open Create policy and define the Salesforce object scope and selection criteria. Start with a small group of closed or inactive records. Include required fields, relationships, and files in the configuration record, along with any exclusions.
Preview the selected records
Choose Preview records and compare the selection with the intended business rule. Check date boundaries, active records, missing values, and related records before running the archive workflow.
Validate the retained copy
Compare record counts and sampled field values with the source. Exercise the retrieval workflow that the business will actually use. Include a user who should have access and one who should not.
Make cleanup a separate decision
Do not use a completed transfer as proof that source records can be removed. Approve a cleanup policy only after retention, dependencies, retrieval, and recovery requirements have been reviewed.
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.
Scope of this example
Complete this pilot without source deletion. Reclamation requires its own verified eligibility, approval, and maintained write freeze. Live Salesforce sharing is not automatically replayed by the archive viewer.
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.
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 archive contains fewer records than expected
Compare the selection rule, source account visibility, date boundaries, API responses, and excluded record types. Reconcile counts before changing the scope.
A historical record lacks useful context
Check whether related records, custom fields, and attachments were included. Test retrieval across the complete business case rather than a single row.
A record should not be removed
Stop the cleanup step and review active dependencies, retention holds, and the approved deletion boundary with the data owner.
SQL Server connections fail or time out
Check the instance address, listener port, network route, authentication mode, certificate trust, and connection account. Separate connection failure from schema or write permission errors.
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