Manage your Environments

Below you will find sections that cover key environment management topics related to the Kaptio Travel Platform, and recommendations associated with maintaining Kaptio on a Salesforce production org.

The intended audience are client admins, architects and technical managers with a fundamental understanding of the Salesforce Platform. If you are new to Salesforce, please review our New to Salesforce? guide.

Delivery Lifecycle Roles & Responsibilities

Kaptio recommends assigning roles to individuals to help establish who is responsible for the setup, maintenance, and improvements to your overall Delivery Lifecycle process. The key roles are:

Product Owner: A role typically associated with Agile & Scrum frameworks. This person plays a key role in helping your organisation understand the business and system requirements for your Kaptio system, and then prioritises any customisation work accordingly. Effective Product Owners:
- Build and manage the product backlog.
- Closely partner with the business executives and your Salesforce team to ensure everyone understands the work items in the backlog.
- Give your Salesforce Team team clear guidance on which features to deliver next.
- Decide when to release improvements with the preference toward more frequent delivery.
- Keep in mind that a Product Owner is not a Project Manager. Product owners are not managing the status of the project. They focus on ensuring the development team delivers the most value to the business as well as representing the Customer. It is important that the Product Owner is one individual to avoid mixed or confusing messages being relayed to the Development team.
Deployment Manager: An individual responsible for the scheduling, refreshing, coordinating and managing of deployments across all environments. Works collaboratively with the Product Owner and Salesforce team to ensure that the tools and processes are being used as effectively as possible.
Salesforce Team: A team of Salesforce Certified Admin & Developers who have in depth knowledge of the Salesforce Platform and the capacity to learn and work with the Kaptio Platform.
Testers: Quality Assurance testers that have in depth knowledge of the business and business systems and who can validate changes on behalf of production users.

Sandbox Data Seeding

In order to set up the Kaptio Travel Platform in a sandbox, we are reliant on key setup records related to the global configuration of objects, such as Kaptio Settings, Business Units, Channels, Services & Packages.

Below are recommended approaches on how to manage Sandbox Seeding:

Use of Full Copy sandboxes, which is dependent on the purchase of additional sandboxes licenses.
Use of Partial Copy sandboxes, which depending on your data volume could work for your environment.
Run script after sandbox creation. This allows admins to specify a single Apex class to perform data setup tasks. This class executes every time the sandbox is copied. This class would be developed and maintained by your team. More information on the SandboxPostCopy Interface can be found here.
Use of 3rd party products. Kaptio Recommends Prodly which already supports a Kaptio Template.

General Kaptio recommendation to deployment managers is:

Restrict the number of sandbox environments, as the more sandbox environments you have will increase the maintenance complexity for seed data.
Carefully plan your sandbox refresh schedule for environments that are not Full Copy Sandboxes, as it may be a complex task to seed or validate partial copies.
Salesforce DX Scratch Orgs are useful if you have established a time-effective solution to data seeding - but keep in mind, there are data volume restrictions on the scratch orgs that need to be considered.

Learn how to refresh and create a new sandbox with these articles:

Kaptio Core API Provisioning

The Kaptio Travel Platform uses the Kaptio Core API to compute complex price, promotion and inventory calculations. Therefore, client production and sandbox orgs need to be connected to an API endpoint. Kaptio currently provides four environments of the Core API and each Salesforce sandbox org is only connected to one environment.

Due to operational and security reasons, each time you refresh and reseed a sandbox, you need to contact Kaptio Support to re-provision the API to the correct environment. Please plan a minimum of 48h for re-provisioning to be completed.

In addition to this there are several restrictions with how the API environments get provisioned:

When using Full Copy or Partial Copy sandboxes, the Salesforce record IDs are the same as from the production org. To ensure data integrity on our API system, each Salesforce Record ID is unique within a single API environment. This means that a Full/Partial Copy sandbox can only be assigned once to a given API environment.
- For example, a Full Copy sandbox used for Staging purposes can be connected to core-staging, and a Partial Copy sandbox used for QA purposes can be connected to core-qa, but then no other Full/Partial Copy sandboxes can then be connected to those API environments.
If you use other data seeding approaches, such as manual seeding, the SandboxPostCopy interface or 3rd party products, Salesforce will generate a unique record ID for those records in the new sandbox and then you can connect as many sandboxes to the same environment. Please note that this has only been possible since January 2020 and could have some issues on a client-by-client basis.

Due to the provisioning limitations, Kaptio recommends:

To remain compatible with the Kaptio Core API environments, restrict the use of Full Copy or Partial Copy sandboxes to three environments.
Carefully plan your sandbox refresh schedule as you are dependent on the Kaptio Support team to re-provision the API and this could take up to 48 hours.

Data Masking

Sandbox environments can contain personal information (PI) and personally identifiable information (PII). PI and PII data includes the names of customers, phone numbers, email addresses, postal addresses and more. Because sandboxes are typically used for development and testing, a larger group of developers, employees, and contractors, that cannot typically access production environments, might need to be given access to sandboxes. Managing sandbox data privacy is often an afterthought and, if implemented, can be time-consuming and difficult.

Instead of manually securing data and access for sandbox orgs, Salesforce Data Mask automatically masks private data in sandboxes. Data Mask uses a fully platform-native approach to mask private data without taking data out of Salesforce or introducing external dependencies.

Data Mask works behind the scenes in three ways:

Anonymization — or making the data anonymous — scrambles a field’s contents into unreadable results. For example, Blake becomes gB1ff95-$.
Pseudonymization converts a field into readable values unrelated to the original value. For example, Kelsey becomes Amber.
Deletion converts a field into an empty data set.

Salesforce Data Mask uses nondeterministic obfuscation, meaning that you cannot unmask the data, even if you try to reverse engineer the approach or use statistical inference attacks to attempt to maliciously hack the data.

Data Mask tool would traditionally be setup and maintained by the Deployment Manager in collaboration with the Salesforce Team.

For more information on the installation, setup and maintenance of Data Masks, see Trailhead Module for Salesforce Data Mask.

Email Deliverability

The Salesforce Platform offers a wide variety of options for configuring email deliverability. Using the Deliverability page in Setup, you can set the email deliverability settings for your sandbox. To control the type of email that your organization sends, use the Access level option in the Access to Send Email section. The available options include:

No access: Prevents all outbound email to and from users.
System email only: Allows only automatically generated emails, such as new user and password reset emails. Especially useful for controlling email sent from sandboxes so that testing and development work does not send test emails to your users. Newly created sandboxes default to System email only.
All email: Allows all types of outbound email.

In cases where testing of emails is needed on a sandbox, the setting has to be changed to All Email. Kaptio recommends masking production data related to personal information, such as email address, to ensure that test emails do not get sent to users or customers. This would be the responsibility of the Deployment Manager.

Tracking Changes & Source Control

For maintaining your Kaptio Travel Platform configuration, it is important to track every change made before deploying into your testing and production environments. There are two types of changes made during the Delivery Lifecycle for Kaptio:

Salesforce Metadata: Metadata relates to the fields, configuration, code, logic, and page layouts that go into building the information architecture and look and feel of your Salesforce environment. Metadata can be imported into Salesforce, deployed via Changes Sets, or deployed via the Salesforce Metadata API. There are several types of Metadata, with each one representing a unique way a business function can be customised. Here are a few broad categories for Metadata types
- Data: the core components of the data structure on which most customisation is built. E.g. Custom Objects, Value Sets, and Custom Apps.
- Programmability: custom code developed on top of the platform. E.g. Apex Classes, Apex Page, and Apex Triggers.
- Presentation: customisation on how users interact with the platform. E.g. Components, VisualForce and Lightning pages.
Salesforce Data: Data relates to the records that a business relies on, such as Users, Accounts, Contacts, Business Units, Channels, to name a few. A common mistake from new users, and seasoned Salesforce Admins alike, is assuming that Metadata and Data are the same — which they are not.

Almost all the changes made to Salesforce Metadata can be viewed in the setup audit trail and/or picked up via Metadata API and maintained in source control setup. [The Metadata Coverage report](https://developer.salesforce.com/docs/metadata-coverage.) shows you which metadata types are supported in Metadata API and other metadata channels. This dynamically generated report is your best source for metadata coverage information.

However, most of the Kaptio base configuration is stored as Salesforce Data. When you make a configuration change to your Kaptio global, item or package data records, you will be required to manually migrate data from one environment to another as this is not deployable metadata, but record data.

A classic example of this is a change to a Template record that controls a client document. Depending on your Delivery Lifecycle process, a content change in the template may be required to go through development, testing and user acceptance approval before being introduced into a production environment. This will require your team to manually migrate the change in the template record, i.e take the modifications from one environment and recreate them exactly in another environment.

Due to the different nature of Salesforce Metadata and Salesforce Data, Kaptio strongly recommends maintaining a change log where Salesforce Team Members log every change (both Metadata or Data) they make during the Delivery Lifecycle process. The overall change log should be verified and consumed by the Deployment Manager. The absolute minimum information collected in the change log should be:

Who made the change?
Does this change require manual migration?
Which component is impacted by this change?
Which orgs currently have the change?
When was the change made in each environment?

This not only helps with knowing what steps need to be taken before moving changes between environments, but it also helps group changes together for release into your production org. For an example of a Change Log Google Spreadsheet, please contact your Kaptio Account Manager.

In addition to the Change Log, there are several tools and approaches available within the Salesforce ecosystem to enable your team to track changes to Metadata via metadata backups or CI pipelines. This requires a certain in depth technical understanding of how Salesforce Metadata works as well as the use of source control and CI applications.

Environments Model

Taking into account the recommendations and some of the limitations covered in the sections above, our recommended use of Sandbox environments is as follows:

Develop and test steps: Each application within your Salesforce production org should have their own Developer sandbox to create and validate customisation. As an example, use a separate developer sandbox for managing your Community application vs your Kaptio application. Developer sandboxes should contain minimum seed data required to develop and test, but no production data. They should be manually seeded, or seeded with the usage of alternative data seeding as determined by your team.
Build release: Each team member migrates their customisations from their respective Developer sandboxes to a shared Developer Pro sandbox for integration. Developer Pro sandboxes do not contain production data, but can be seeded with more data than the developer sandboxes. Here, changes from multiple environments can be tested together from a quality assurance perspective. This environment is often called "SIT" (System Integration Testing).
Test release: For user acceptance testing, your team should use a Full sandbox to create a complete replica of production, but use Data masking to hide any PI/PII information. This environment is often called “Staging” or “UAT”.
Release: After the release is in production, the team can use the Full sandbox created in the last step to train users without exposing PI/PII data during training.

Deployment Tools

When a team member has finished with customisations and local testing, they need to deploy their metadata changes to the integrated test environment (for example, an SIT Dev Pro Sandbox) and manually migrate records or execute any manual steps required documented in the change log.

Although the record data needs to be moved manually, there are three common ways to deploy the metadata changes:

Using Declarative Change Sets
Using ANT Scripts either via manual execution or via CI (see these setup examples using Travis CI, Bitbucket Pipeline)
Using 3rd party products such as ClickDeploy or Copado.