> ## Documentation Index
> Fetch the complete documentation index at: https://support.fieldko.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Manage Releases: Sandboxes, Deployments, and Package Upgrades

> Test FieldKo changes in a sandbox, prepare a sandbox after refresh, deploy your changes, and upgrade the FieldKo packages safely.

Changes to layouts, fields, flows, and FieldKo settings affect every rep's app at their next sync, so test them before they reach production. Use this page to choose a sandbox, prepare it after a refresh so the FieldKo Atlas app works there, move your changes to production, and upgrade the FieldKo packages with a repeatable checklist.

## User Permissions Needed

| To do this | You need |
| - | - |
| Create and refresh sandboxes | Manage Sandbox permission |
| Deploy change sets | Deploy Change Sets and Modify Metadata Through Metadata API Functions permissions |
| Install and upgrade packages | Download AppExchange Packages permission |
| Run the Metadata Collector | FieldKo Manager Permission Set and FieldKo Native Permission Set |

## Choose a Sandbox

Salesforce offers Developer, Developer Pro, Partial Copy, and Full sandboxes. Developer sandboxes copy your configuration but no data. Partial Copy sandboxes add a sample of data, and Full sandboxes copy all of it. Which types you have depends on your edition and contract. See [Sandboxes: Staging Environments for Customizing and Testing](https://help.salesforce.com/s/articleView?id=sf.create_test_instance.htm\&type=5) in Salesforce Help.

For FieldKo, test sync and reports in a sandbox with realistic data: accounts with owners, call cycles, and visits. In a Developer sandbox, load a small test set first. See [Import and Update Data](/platform/data/import).

## Prepare a Sandbox After a Refresh

A new or refreshed sandbox has its own domain and its own collected metadata, so the app doesn't work there until you complete these steps:

<Steps>
  <Step title="Add the Sandbox's Remote Site Setting">
    The sandbox's Visualforce domain for FieldKo Native is different from production. From the App Launcher, find and select **Metadata Collector**, and copy the domain from your browser's address bar. Then add it as a remote site. See [Remote Site Settings](/admin/installation#remote-site-settings).
  </Step>

  <Step title="Run the Metadata Collector">
    Click **Collect Objects and Layouts Metadata**, and then **Collect Profiles Metadata**. See [Run the Metadata Collector](/admin/offline-data#run-the-metadata-collector).
  </Step>

  <Step title="Check FieldKo Settings and Jobs">
    Check that FieldKo custom settings, such as **Sync Configurations** and **Visit Configurations**, have the values you expect. From Setup, in the Quick Find box, enter `Scheduled Jobs`, and then select **Scheduled Jobs**, and schedule any FieldKo jobs you need to test. See [Scheduled Jobs](/admin/installation#scheduled-jobs).
  </Step>

  <Step title="Decide About Email">
    New and refreshed sandboxes send only system email, and Salesforce changes users' email addresses so they don't receive sandbox email. To test visit summary or order emails, update the test users' email addresses and change **Deliverability** in Setup. Never send test emails to customers' contacts.
  </Step>

  <Step title="Check Test Reps">
    Make sure each test rep is active, has the FieldKo permission sets, owns test accounts, and has an active call cycle that covers today.
  </Step>

  <Step title="Log In to the Sandbox from the App">
    On the app's login page, use the login server picker to choose the sandbox server, or add your sandbox's My Domain login URL, and then log in with the sandbox username. See [Log In and Set Up the App](/getting-started/sign-in).
  </Step>
</Steps>

<Warning>
  Logging in to a different org on a device clears the previous user's offline data without uploading it. Use test devices for sandbox testing, or make sure the rep has synced everything before they switch orgs.
</Warning>

## Move Your Changes to Production

Build and test your own changes, such as fields, layouts, record types, validation rules, and flows, in the sandbox, and then deploy them:

* **Change sets** move metadata between your production org and its sandboxes. See [Change Sets](https://help.salesforce.com/s/articleView?id=sf.changesets.htm\&type=5) in Salesforce Help.
* **DevOps Center** tracks changes as work items and moves them through a pipeline with source control. See [DevOps Center](https://help.salesforce.com/s/articleView?id=sf.devops_center_overview.htm\&type=5) in Salesforce Help.

Keep these FieldKo points in mind:

* **You can't change FieldKo's packaged components,** such as its objects' packaged fields, flows, and Apex. Deploy only your own changes.
* **Custom setting values aren't metadata.** Most FieldKo settings are custom settings, so change sets don't move their values. Re-enter them in production, or load them with Data Loader. Custom metadata records, such as **FieldKo Layout Override** and **Visit Type**, can be deployed.
* **Rerun the Metadata Collector in production** after you deploy layouts, fields, or record types, and then ask reps to tap **Sync**, and then run **Reset Sync**.

## Upgrade the FieldKo Packages

FieldKo package upgrades don't change your settings, but they can add fields, objects, and features that the app uses. Upgrade in a sandbox first:

1. Get the upgrade links from your FieldKo contact. Upgrade the FieldKo package first, and then the FieldKo Native package.
2. In the sandbox, rerun the Metadata Collector, and then test your key flows: login, visits, surveys, orders, ranging, and your own automation.
3. Review what's new. The [FieldKo Atlas release notes](/release-notes/fieldko-atlas) cover the app. For package changes, ask your FieldKo contact.
4. Upgrade production, preferably outside reps' working hours.
5. Rerun the Metadata Collector in production.
6. If layouts or fields changed, ask reps to tap **Sync**, and then run [Reset Sync](/sync/reset-sync). Syncing first uploads their unsynced changes.
7. Check that reps' syncs succeed in [Sync Details](/admin/support-diagnostics#sync-details), and that reps run the app version you expect, using **Mobile App Version** on their **Attendance** records.

## Release Checklist

Use this checklist for every release, whether it's your own change or a package upgrade.

| When | Task | Done When |
| - | - | - |
| Before | Test the change in a sandbox, including a real rep sync on a device | A test rep completes visits offline and syncs without issues |
| Before | Check automation for bulk safety and fault paths | New flows pass a full-day offline sync test. See [Design Automation for FieldKo](/platform/automate/design-automation). |
| Before | Tell reps when to sync and whether to reset | Reps know to sync before the release |
| During | Deploy changes or upgrade packages | The deployment or upgrade succeeds |
| During | Re-enter changed custom setting values | Production settings match the sandbox |
| After | Rerun the Metadata Collector | Both success messages appear |
| After | Ask reps to sync, and then reset if layouts or fields changed | Reps see the new fields and layouts |
| After | Monitor sync details and errors for a few days | No new **Partial Sync** or **Failed** records |

## See Also

* [Install and Set Up FieldKo](/admin/installation)
* [Control What Syncs to the App](/admin/offline-data)
* [Diagnose Rep Issues](/admin/support-diagnostics)
* [Extend FieldKo Safely](/platform/customize/extend-safely)
* [FieldKo Atlas Release Notes](/release-notes/fieldko-atlas)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.