Caseblocks Logo

How to Import or Export a CaseBlocks Configuration

How to Import or Export a CaseBlocks Configuration

CaseBlocks configuration can be exported from one account and imported into another using a tool called cbcli.  Although it’s not available to download yet, please contact us if you’d like to arrange early access.

The CaseBlocks CLI helps administrators and developers move CaseBlocks configuration between different environments e.g. from a production environment into a sandbox environment and vice versa.

Getting started

It’s best if you create a parent directory called cbprojects which will then contain subdirectories for each of the projects you’re intending to import and export from.

That way you’ll end up with the following tree:


Also, make sure you run the cbcli commands from the cbprojects folder.

Initializing a local project

To set up a local directory structure to export and import configuration details out of CaseBlocks run:

cbcli init --name client_test --host --token <admin_user_token>

This will create a client_test folder below the current working directory, pointing at the production environment, using the specified admin user’s token. The host is optional and assumes if not specified.

A config.yml file is created inside your project’s directory containing the credentials to allow cbcli to connect to CaseBlocks. Please ensure that this file is not stored inside any source code management systems such as Git.
In the case of Git, you can edit your .gitignore and add the config.yml file.

Exporting a remote project

Use the following syntax to export the configuration of a remote CaseBlocks project:

cbcli export --project=client_test

The following subdirectories will be populated:

/First Line Support.yaml
/Open Complaints.yaml

Importing a remote project

To import a local project into a remote CaseBlocks account, use the following syntax, specifying which objects to include:

cbcli import --project projectName --include=caseTypes,buckets[All Complaints]

The import command will only create new objects, meaning that in the example above if the “All Complaints” bucket existed, then request to import the bucket definition would be ignored.
We may want to introduce a –force flag to overwrite existing configuration objects.

Copying config from one environment to another

One of the issues when migrating your configuration is that the ID numbers in the target system will not be the same as from the original unless you are extremely lucky! In order to resolve this issue, we added a copy command that will copy the files from one project to another, removing the id’s as they are copied. This means that the search will be done on the name to check for existing objects, if they exist then they are updated, if they don’t then they will be created.

cbcli copy --from local-dev --to staging

The example command above copies from a project named ‘local-dev’ and places the updated files in the staging project. All this happens on your local machine, nothing is sent to the server yet, this allows you to evaluate any changes with source control software in order to control what is being moved.