🔗 Prerequisites
Features
What you get with this outcome
Ship with Confidence
Every Kaptio implementation needs a clear path from development to production. The deployment pipeline defines which Salesforce orgs exist, who owns them, how changes flow between them, and how Kaptio package upgrades are promoted safely. Getting this right from day one prevents environment drift, broken deployments, and the accumulation of deprecated sandboxes.
Visual coming soon
Environment Strategy
Environment Strategy
Map out your Salesforce org landscape — development sandboxes for Kaptio engineering, QA for validation, SIT for integration testing, UAT for business acceptance, and production for live operations. Each org has a clear owner and purpose.
- ✓Clear org map with ownership assignments
- ✓Purpose-defined environments prevent data contamination
- ✓Scalable from simple (3-org) to complex (10+ org) strategies
- ✓Deprecation path for retired environments
Visual coming soon
Username Conventions
Username Conventions
Standardize user naming across all orgs using the {email}.orgname pattern. This prevents login conflicts, simplifies user management, and makes it immediately clear which org a user belongs to.
- ✓Consistent naming across all environments
- ✓No login conflicts between sandboxes
- ✓Easy identification of org context
- ✓Simplified user provisioning
Visual coming soon
Deployment & Data Seeding Tooling
Deployment & Data Seeding Tooling
Select and configure appropriate tooling for managed deployments and data seeding between environments. Automate the promotion of metadata, configuration, and data from dev through to production with audit trails and rollback capability. Common tools include Gearset, Copado, or Salesforce DevOps Center.
- ✓Deployment promotion pipeline configured
- ✓Audit trail for all deployments
- ✓Rollback capability for failed deployments
- ✓Repeatable deployment runbooks
Visual coming soon
Promotion Path
Promotion Path
Define how changes flow from development through to production — which gates exist, who approves promotions, and what testing is required at each stage. Includes the process for Kaptio managed package upgrades.
- ✓Clear promotion gates and approval workflows
- ✓Kaptio package upgrade runbook
- ✓Sandbox refresh strategy and scheduling
- ✓Data management between environments
User Journey
Step-by-step flow from start to finish
🗺️User Journey Flow
Follow the steps from start to finish
Implementation Plan
How to implement this outcome
📅 Project Overview
Environment Design
1-2 days- • Document environment strategy (org map)
- • Agree ownership model (Kaptio vs customer)
- • Define username convention
- • Plan sandbox provisioning
Provisioning & Configuration
2-3 days- • Provision development and QA sandboxes
- • Provision SIT and UAT sandboxes
- • Create users with naming convention
- • Configure deployment promotion pipeline
Validation
1-2 days- • Test promotion from dev to QA
- • Test promotion from QA to SIT
- • Document deployment runbook
Resources
Configs, tools, and documentation to help you
Environment Strategy
Every Kaptio implementation follows a standard environment pipeline. The number and configuration of environments scales with the complexity of the implementation.
Standard Environment Pipeline
| Environment | Owner | Purpose | Data |
|---|---|---|---|
| Dev | Kaptio | Initial configuration and development | Template + test data |
| QA | Kaptio | QA validation and deployment rehearsal | Promoted from Dev via deployment tooling |
| SIT | Customer | Integration testing, story acceptance | Promoted from QA via deployment tooling |
| UAT | Customer | End-user acceptance testing, training | Promoted from SIT via deployment tooling |
| Production | Customer | Live operations | Go-live cutover |
Username Convention
When creating users across multiple orgs, use the naming pattern:
{email}.orgnameExample: For a user ivan.gakic@kaptio.com in the Dev org named kaptiodev:
- Username:
ivan.gakic@kaptio.com.kaptiodev
This prevents login conflicts between sandboxes and makes it immediately clear which org a user session belongs to.
Deployment & Data Seeding Tooling
The appropriate tooling for environment deployments and data seeding is chosen per implementation. Common options include Gearset, Copado, Salesforce DevOps Center, or SFDX-based pipelines. The chosen tool should provide:
- Comparison jobs between environments
- Managed deployments with conflict resolution
- Audit trail for all promotions
- Rollback capability for failed deployments
- Data seeding to populate environments with representative test data
Promotion Path
Changes flow in one direction through the pipeline:
Dev -> QA -> SIT -> UAT -> Production
Each gate requires:
- Successful deployment in the source environment
- Test pass at the appropriate level (unit, integration, acceptance)
- Approval from the gate owner (Kaptio for dev->QA, customer for SIT->UAT->Prod)
Sandbox Refresh Strategy
Sandboxes should be refreshed periodically to stay aligned with production:
- Full sandboxes (SIT, UAT): Refresh quarterly or before major releases
- Developer sandboxes (Dev, QA): Refresh as needed, more frequently
- After refresh: Re-apply Kaptio package, re-create test data, verify integrations
Lessons from Real Implementations
- Never install beta packages on shared environments — use dedicated scratch orgs or developer sandboxes
- Deprecate unused environments formally — document the decision and remove access
- Keep a single shared admin credential only as a last resort — prefer per-user accounts with appropriate profiles
- Plan for integration environments separately when third-party systems can only connect to a single sandbox
Common Pitfalls
Avoid these implementation mistakes
Accumulating deprecated sandboxes without cleaning them up — creates confusion and wastes Salesforce sandbox allocation
Installing beta packages on shared environments — can break an org permanently (as seen in real implementations)
Sharing admin credentials via password managers instead of per-user accounts — creates audit trail gaps
Skipping the SIT environment — integration issues surface too late if you go straight from QA to UAT
Not planning sandbox refreshes — environments drift from production over time, making deployments unreliable
Mixing test data with real data in shared environments — hard to distinguish and clean up