Skip to main content
When working within a single-tenant Enterprise Knowledge (EK) Cloud environment, it is not possible to have separate development and production tenants by default. This article outlines the recommended approach for managing your development lifecycle and promoting solutions from development to production within the same tenant. The core recommendation is to treat Projects in EK as your environment boundary. Rather than building directly in a production project, you should maintain a dedicated development project where all configuration, testing, and iteration takes place before any solution is promoted to production.

Development Phase

All solution development should happen inside a designated dev project. This includes configuring knowledge sources, building and testing agents, setting up tools and integrations, and defining workflows. Keeping this work isolated in a dev project ensures that your production environment remains stable and unaffected during active development. Once development is complete, the solution should go through User Acceptance Testing (UAT) within that same dev project. Stakeholders and end users can validate behavior, test edge cases, and sign off on the solution before any promotion takes place. Only after UAT is approved should you proceed to create the production project.

Promoting to Production

EK Cloud provides two methods to promote a dev project to production within the same tenant: Option 1 – Export and Import Export the dev project from EK and import it as a new project within the same tenant. This gives you a clean production project that mirrors the dev configuration at the time of export. Option 2 – Clone and Rename Clone the dev project directly within the tenant, then rename the cloned project to reflect its production purpose. Both projects will co-exist in the same tenant, and the dev project is preserved in its current state. Either method results in a new, independent project that serves as your production environment.

Post-Migration Steps

Regardless of which method you use, several items require manual attention after the production project is created. These do not carry over automatically and must be reconfigured before the solution is live.

Project Members

Project members are not transferred during either an export/import or a clone operation. All users who need access to the production project must be added manually.

Third-Party Service Authentication

Any integrations connected to external services — such as cloud storage providers, CRMs, or other SaaS platforms — will need to be re-authenticated in the new production project. Credentials and OAuth connections are scoped to the project they were originally configured in and are not transferred during export/import or cloning.

API Keys for Tools

If any tools within the solution rely on API keys, those keys must be re-issued and reconnected within the production project. Do not reuse dev API keys in production, both for security reasons and because dev keys may have different rate limits or access scopes.

Automation Anywhere APA Control Room Connections

If the solution is connected to an Automation Anywhere APA Control Room instance, that connection must be re-established in the production project pointing to the production APA Control Room. Dev and production APA environments are separate, and the connection configured in the dev project will reference the dev APA instance. Failing to update this connection means your production EK solution will continue triggering or communicating with the development APA environment.

Summary

StepAction Required
Development & UATWork entirely within the dev project
Promote to ProdExport/Import or Clone and Rename
Project membersRe-add all members to the prod project
Third-party servicesRe-authenticate in the prod project
Tool API keysRe-issue and reconnect in the prod project
AA APA connectionsReconnect to the prod APA Control Room

Notes

  • There is no automated sync between dev and prod projects. Any changes made post-UAT in the dev project must be manually re-promoted.
  • It is recommended to maintain the dev project after go-live to support future iterations and testing.
  • Project naming conventions should clearly distinguish dev from prod to avoid accidental configuration in the wrong environment (e.g., MyProject_DEV and MyProject_PROD).