Embedded Environments FAQs

Get answers to frequently asked questions (FAQs) about Environments for Embedded customers.

Who can access the Deployments tab?

The Deployments tab is accessible for the Embedded Partner (EP) and collaborators with permission. Refer to Embedded Environments roles for more information.

Who can access different environments?

Access to each environment can be defined for a collaborator. It is possible to assign a different role for each environment. Refer to Embedded Environments roles for more information.

Who can make deployments to another environment?

A user must have deployment permission on both the origin and target environment to make a deployment. Refer to Embedded Environments roles for more information.

Can a collaborator deploy to an environment they don’t have access or deployment access to?

No. A collaborator must have access to at least two environments to view the Deployments tab, and deployment permission in both environments.

If a collaborator has deployment access on two environments, they can only choose one environment as a target. Whenever the collaborator is logged into an environment in which they do not have deployment permission, they cannot access the Deployments tab.

ENVIRONMENT ACCESS

The Embedded Partner (EP) manages access to different environments (Development, Test, Production) within an Embedded Customer's (EC) workspace through their UI in a fully embedded environment. The EP is responsible for generating new JWT tokens to enable seamless switching between environments without compromising security. This ensures that ECs can only access the environments they are permitted to, maintaining the integrity of each environment's operations.

What happens when importing an SDK source code using RLCM in Development (package including connector)?

The connector becomes exclusively available in the current environment. It does not appear in other environments unless deployed.

SHARED CONNECTORS

We always encourage partners to use shared connectors for a better and unified experience.

What occurs during a deployment from Development to Production or Test for an SDK Connector?

If the SDK connector is selected to be included in the deployment package, the connector, along with any updates or source code changes, is successfully included in the Production or Test environment. Each environment has distinct connector IDs, indicating separate instances. The SDK connector displays under Tools> connector SDK for each environment where it is available.

How does installing an SDK Connector through a sharing link affect its availability?

Installing the SDK connector in the customer’s Development workspace through a sharing link makes it available as a private connector in Development. Without the connector, importing the package fails. The connector is not initially present in other environments after installation.

Installation with a private link makes the connector available in the current environment. Without the connector, importing a package that uses it fails. The connector is not initially present in other environments after installation.

How does editing the connector version in Development impact Production?

Modifying the version in Development does not affect the version in Production. However, deploying a new version from Development to Production updates the connector in Production, maintaining the same ID.

What behaviors have been observed SDK Connectors across environments?

Connectors operate independently between Development, Test, and Production. Deployment transfers connectors with updates, maintaining consistency. Additionally, using a private link for sharing the connector matches the behavior observed with RLCM imports.

What happens to Lookup Tables when deploying a project?

Lookup Tables are included in the deployment package regardless of the table scope (global or project). Lookup Table content is only included in the deployment if you choose to include this data.