Import and export configuration

This article explains how to move your GoMeddo configuration from one Salesforce org to another with the Export / Import Configuration page in GoMeddo Settings. For example, from a sandbox to production after you have finished configuring, or from production into a freshly refreshed sandbox.

Most GoMeddo configuration lives in Salesforce records (Calendars, Dimensions, Reservation Types, GoMeddo Rules, and so on), not in metadata, so it is not part of a regular Salesforce deployment. The Export / Import Configuration page lets an administrator download that configuration as a single file and load it into another org, without Data Loader, scripts, or the SFDX Data Move Utility.

How it works

1. In the source org, you export the configuration. GoMeddo downloads a JSON file to your computer.

2. In the target org, you upload that file. GoMeddo first shows you a preview of what would change, without changing anything yet.

3. When you confirm, GoMeddo imports the file:

   • Records that already exist in the target org are updated. GoMeddo matches them by name or other identifying fields, see What is exported below.

   • Records that don't exist yet are created.

   • Nothing is deleted. Records that exist in the target org but not in the file are left untouched.

   • The import is all or nothing: if a single record fails, the whole import is rolled back and the target org is left exactly as it was.

Recommended workflow

For the most common case, moving a finished configuration from a sandbox to production:

1. Finish and test your configuration in a sandbox.

2. Make sure the custom objects, custom fields, and record types your configuration uses exist in production.

3. Make sure the Resources, Resource Types, Staff, Services, Groups, Hover Definitions, and Related List configuration that your configuration refers to exist in production under the same names.

4. Export from the sandbox.

5. Upload the file in production and check the preview, including the References that won't resolve panel.

6. Run the import.

7. On the GoMeddo Settings page in production, set the toggles to match the sandbox. The export doesn't include them.

8. Open a calendar and a reservation form in production to verify the result.

Export from the source org

1. In the source org, open the App Launcher and search for GoMeddo Settings.

2. In the left-hand navigation, under GoMeddo Settings, select Export / Import Configuration.

3. Stay on the Export configuration tab.

4. Optional: expand Objects to include and deselect the objects you don't want to move. By default, everything is selected.

5. Click Export & download.

If you deselect an object that other selected objects depend on (for example Dimensions while keeping Dimension Fields), a Dependency warning appears. The deselected records are still written to the file, but only as references: GoMeddo never creates or updates them in the target org, so they must already exist there under the same name.

GoMeddo downloads a file called gomeddo-configuration-<date>.json. It contains the full state of every exported record, including the GoMeddo version and org it came from. You can keep it as a backup of your configuration, or check it into version control.

Import into the target org

Upload the file

1. In the target org, go to GoMeddo Settings > Export / Import Configuration.

2. Click the Import configuration tab.

3. Under Configuration file, upload the exported file. The maximum file size is 5 MB.

GoMeddo analyzes the file against the target org and shows a preview. Nothing has been changed yet.

Review the preview

For every object in the file, the preview shows:

Use the checkboxes to leave out objects you don't want to import. The preview is recalculated after every change. As on the export side, deselecting an object that others depend on shows a Dependency warning.

Below the table, check the panels and resolve what they report:

• These problems block the import: the import can't run until you fix these. For example, a Filterable Field that refers to a field that doesn't exist in this org, or a file with more than 10,000 records. Fix the cause in the org, or deselect the object.

• References that won't resolve: configuration records that refer to a Resource, Resource Type, Staff, Service, Group, Hover Definition, or Related List that GoMeddo couldn't find by name in this org. These records are still imported, with the missing reference left blank. Select I understand these references won't resolve to continue, or create the missing records first and upload the file again.

• Warnings: for example, a version difference between the orgs, a file that was exported from this same org, or a record that appears twice in the file. Only the first occurrence of a duplicate record is imported.

Run the import

1. Click Import.

2. Confirm the import in the dialog that appears. The dialog reads: Matching records will be updated and missing records will be created in this org. This cannot be undone.

Check the result

The result table shows, per object, how many records were Created, Updated, and Failed.

• If the import succeeded, you see The configuration was imported successfully.

• If one or more records were rejected, for example by a GoMeddo Rule that doesn't compile in this org, you see The import failed and no changes were made. The whole import was rolled back. The errors below the table name each record and the reason. Fix the cause, then import again.

What is exported

The export contains two groups of objects: GoMeddo configuration records and your own records. You can include or leave out each object individually.

GoMeddo configuration

Names are matched case-insensitively: a Calendar called "Meeting Rooms" in the file updates a Calendar called "meeting rooms" in the target org.

Your records

If you use your own standard or custom objects as dimensions (for example a custom Room or Vehicle object), their records can be exported and imported as well, so the configuration that points at them keeps working in the target org. These objects are listed under Your records and are matched by their Name field. Objects whose Name is an auto-number cannot be matched reliably and are not offered.

What is not exported

• Resources, Resource Types, Staff, Services, and Groups. These are the things being booked, not configuration, and their names are not unique within a hierarchy. Configuration that refers to them (for example a Dimension Junction pointing at a Resource) is linked to the record with the same name in the target org. If no such record exists, the import preview lists it under References that won't resolve. To move these records themselves, see Deploy Resource/Staff/Availabilities records.

• Reservations, Reservation Contacts, Service Reservations, Availabilities, and other transactional data.

• Hover Definitions and Related List configuration. Configuration that refers to them is linked to the record with the same name in the target org, but the records themselves are not transferred. Fields To Set that belong to a related list are left out of the export.

• GoMeddo Settings (the toggles on the GoMeddo Settings page), permission sets, users, profiles, and any object not listed above.

Good to know

• The file holds the full state of each record. A field that is empty in the source org is also emptied in the target org when the record is updated. Checkboxes and required fields are never emptied.

• GoMeddo Rules are recompiled on import. Their formulas are validated against the target org, exactly as when you save a rule by hand. A formula that refers to a field that doesn't exist in the target org makes the import fail with a clear error.

• Record types (for example Conflict Rule and Filter Rule on GoMeddo Rules) are matched by their developer name and must exist in the target org.

• Importing the same file twice is safe. The second import finds all records and updates them with the same values.

• At most 10,000 records per object can be exported, and at most 10,000 records in total per import. When you hit this limit, deselect objects or split the import.

• Both directions work. Sandbox to production is the most common direction, but production to sandbox (for example after a sandbox refresh) works the same way.

Troubleshooting

Related articles

• Deploy GoMeddo configuration data across orgs

• Deploy Configuration records (SFDX Data Move Utility, for versions before 7.4)

• Deploy Resource/Staff/Availabilities records

• Reset configuration data (Sandbox Refresh)

• GoMeddo Installer