Instance activation guide – Help Center

Step 1: Look up available dentsu Client Keys

In your Translate app instance, query the instance configuration to see all dentsu Client Keys provisioned for your account:

SELECT
  dentsu_client_key,
  status,
  is_default,
  legacy,
  client_schema,
  activation_code
FROM <application_name>.app_public.instance_config
ORDER BY
  legacy DESC,
  dentsu_client_key;

Replace <application_name> with your Translate app instance database name. This returns all dentsu Client Keys provisioned for your account by the provider. Each row represents a key that can be activated in this Translate app instance.

Column	Description
`dentsu_client_key`	The client key identifier
`status`	`AVAILABLE` (not yet activated), `ACTIVATED` (active), or `NOT AVAILABLE` (belongs to a different instance group and cannot be activated in this Translate app instance)
`legacy`	`TRUE` if this is a pre-existing key migrated from the previous version and not yet activated. Once activated, this changes to `FALSE`. New keys are always `FALSE`.
`activation_code`	The code needed to activate this key
`client_schema`	The schema where `_to_table` results will be written after activation (e.g. `<client_key>`)

Step 2: Activate legacy keys

If you have any keys with legacy=TRUE, activate them in your current (existing) Translate app instance. Activating creates a dedicated client schema for your key and ensures all future _to_table results are written to a consistent location. This prepares your workflows for the eventual retirement of the legacy results schema and for potential multi-tenant activations where additional dentsu Client Keys may be provisioned for your account.

Before activating, be aware of the schema change. Activation changes where _to_table template results are written:

Before activation (legacy mode): Results are written to both the legacy schema (results.<template>_match) and the new client schema (<client_key>.<template>_match_output). The table structure is the same, but table names differ.
After activation: Results are written to the new client schema only (<client_key>.<template>_match_output). The legacy results schema stops receiving new data.

If you have downstream processes, pipelines, or code that reads from the legacy results schema, update them to read from <client_key> before activating. You can use the legacy dual-write period to validate — both locations contain the same data while the instance remains in legacy mode, so you can point your processes at the new schema and confirm everything works before committing to activation.

Once ready, activate each legacy key:

CALL <application_name>.app_public.activate_instance('<ACTIVATION_CODE>');

Replace <activation_code> with the value from Step 1 for the legacy row.

Verify after activation

SELECT
  dentsu_client_key,
  status,
  is_default,
  legacy,
  client_schema
FROM <application_name>.app_public.instance_config
ORDER BY dentsu_client_key;

Confirm that:

The key now shows status=AVAILABLE and legacy=FAKSE (activation transitions the key from legacy to activated mode)
A client schema has been created (e.g. <client_key>)
Any non-legacy keys assigned to a different instance group now show status=NOT AVAILABLE — this is expected and confirms the isolation is working

Step 3: Activate new keys

If you have keys with legacy=FALSE and status=AVAILABLE, these are newly provisioned dentsu Client Keys ready for activation.

If this is your only key (no legacy keys), activate it directly in your current Translate app instance:

CALL <application_name>.app_public.activate_instance('<ACTIVATION_CODE>');

Multi-tenant scenarios

If you have already activated a legacy key (Step 2) and the new key shows status=NOT AVAILABLE, it belongs to a different instance group and requires a separate Translate app instance:

Install a new Translate app instance from the Snowflake Marketplace listing

In the new Translate app instance, query available keys:

SELECT
  dentsu_client_key,
  status,
  is_default,
  legacy,
  client_schema,
  activation_code
FROM
  <application_name>.app_public.instance_config
ORDER BY
  legacy DESC,
  dentsu_client_key;

Locate the key you want to activate (status=AVAILABLE)

Activate it:

CALL <application_name>.app_public.activate_instance('<ACTIVATION_CODE>');

Verify:

SELECT
  dentsu_client_key,
  status,
  is_default,
  legacy,
  client_schema
FROM
  <application_name>.app_public.instance_config
ORDER BY
  dentsu_client_key;

Confirm that the key shows status=ACTIVATED and the client schema has been created

Repeat for each additional dentsu Client Key that requires its own Translate app instance.

Important: New (non-legacy) keys always write _to_table results to the client schema only (<client_key>.<template>_match_output). There is no dual-write to the legacy results schema.

Important notes

Order matters. Always activate legacy keys first in your existing Translate app instance before installing new app instances for non-legacy keys. This ensures proper instance group isolation.
One instance group per Translate app instance. Each Translate app instance can only hold keys from the same instance group. Attempting to activate a key from a different group returns: "is not authorized for this instance of the app."
Legacy keys without activation. Legacy keys provide data access without explicit activation, but activating them is recommended to establish a dedicated client schema, consolidate your result output location, and prepare for potential multi-tenant activations.
Default key. The first activated key becomes the default. To change the default, use:
```
CALL <application_name>.app_public.activate_instance('<ACTIVATION_CODE>', TRUE);
```
Deactivation. To deactivate a key:
```
CALL <application_name>.app_public.deactivate_instance('<ACTIVATION_CODE>');
```
If the deactivated key was the default, the remaining activated key auto-promotes.