SDLC Key Concepts
The following concepts explain how Software Development Lifecycle (SDLC) works and what they are made of.
Workspace
A Workspace represents a logical SDLC environment, such as development, test, or production. Each workspace provides an isolated environment to manage users, assets, and resources throughout the development lifecycle.
Key characteristics of a workspace include:
Each workspace maintains its own users, assets, configuration, execution context, and storage, preventing changes in one environment from affecting another.
Using separate workspaces for development, testing, and production keeps in-progress, validated, and production assets isolated throughout the SDLC.
Workspace-scoped roles and permissions, group-based access, SCIM-based user and group provisioning (where available), and service accounts or service principals help control access to assets and operations.
Each workspace can maintain its own datasets, connections, storage configuration, credentials, retention policies, and governance settings, allowing different environments to operate independently.
Package
A package serves as a container that groups a workflow and its related dependencies—such as macros, references to datasets, and connections—into an immutable, versioned bundle. This structure maintains consistency and traceability throughout the workflow’s lifecycle and across SDLC environments.
A package is created within the current workspace and becomes available in other workspaces only after the promotion request is approved.
Key characteristics of a package include:
After a package is created, its contents can't be modified. Any workflow changes require creating a new package version, to prevent unintended changes after promotion.
Each package represents a specific version of a workflow, providing a clear release history that supports auditing, comparison, and rollback.
A package contains references to the workflow and its dependencies, including Cloud Native, Standard, and Live Query workflows, datasets, connections, and embedded macros. Environment-specific resources aren't copied between workspaces. Instead, dependency references are resolved in the destination workspace during promotion.
Environment-specific mapping:
For cloud workflows, dataset references are mapped to datasets in the destination workspace, allowing each environment to maintain its own data, storage locations, governance policies, and access controls.
For desktop workflows, Workspace Execution connection references are mapped to corresponding Workspace Execution connections in the destination workspace. This ensures the credentials and connection ownership remain within the destination environment.
Packages can be run for validation, allowing users to test the exact package that will be promoted.
Packages appear in the Library page, including the SDLC Manager, All Assets, and Recents pages, where users can locate and filter package assets.
Packages provide a stable, versioned artifact for review, validation, and promotion, separating workflow development from the release process.
Note
Datasets and connections referenced within a package are not transferred across workspaces. Instead, they are resolved in the destination workspace during the review and approval process, based on the workflow type:
Designer Cloud workflows: Dataset references are resolved at approval through Dataset Mapping.
Desktop workflows: Connection references are resolved through Connection Mapping (Workspace Execution) and are persisted by connection ID.
Promotion Request
A promotion request is a persistent, governed object used to request the promotion of a package to an upstream workspace. A promotion request doesn't create a package in the destination workspace until it is approved, providing a controlled and auditable promotion process.
Users can initiate a promotion request from an existing package by selecting the Request Promotion action available on the package’s asset details page or through the three-dot menu.
Key characteristics of a promotion request include:
A promotion request doesn't create a package in the destination workspace until it is approved. This ensures that only reviewed and approved packages are promoted between workspaces.
A promotion request progresses through the following statuses:
Waiting for Approval: The promotion request is awaiting review by an authorized user in the destination workspace.
Approved: The promotion request has been reviewed, dependencies have been mapped, and the package has been validated. Approval creates the package in the destination workspace.
Rejected: The promotion request has been reviewed, but wasn't approved. No package is created in the destination workspace.
Note
Prior to approval of the promotion request, a package is not available.
If a promotion request is rejected, the system doesn't create a package in the upstream workspace.
Promotion requests can be executed before approval, allowing reviewers to validate mapped dependencies and verify that the workflow functions correctly in the destination environment.
Each promotion request records information such as the requester, approvers, destination workspace, justification, status, timestamps, and other audit metadata, providing a complete record of the promotion process.