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 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.

In an ideal world, each team member should have their own sandbox, but due to the seeding complications, and depending on the frequency of changes and refreshes scheduled, this might be difficult to maintain.
Kaptio recommends initial testing and validation be done on the same org as the change, before moving to an integration environment.

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.

The model can be changed slightly with introducing a dedicated Training environment, where Partial Copy Sandboxes can be useful.

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.

Kaptio recommends mastering the use of Change Sets initially as they are the simplest to use and maintain. The recommendations by topic in this document does not change depending on the choice of a deployment tool.

Once System Integration Testing is completed, the team member will deploy his/her changes to the Full Sandbox (Staging / UAT), executing the same steps as before but now targeting a different environment. Once verified within the Full Sandbox, the final production deployment can be executed.

Please note that this section only describes the process for deploying your customisations, and should not be confused with the upgrade process for your Kaptio Travel Platform (covered in the section below).

Kaptio Major Release Readiness

At Kaptio, we are proud to deliver new features and enhancements to you three times a year during our major seasonal upgrades: Spring, Summer, and Winter. These upgrades are aligned with Salesforce release schedules, with our releases occurring several weeks after the Salesforce seasonal releases. To learn more about our Major releases, see our Major Release Section on our Release Notes Portal.

Kaptio announces a release date on our Release Notes Portal 4-6 weeks before it gets released to the first customer sandbox. The release date represents the first available date the release will become available for a client to test on their sandboxes. On the week of the release, Kaptio will publish the Release Notes, which contains all the details about what is in the release.

Your Customer Success Manager will reach out to your Administrator to set a sandbox upgrade date. Depending on the other projects that are going on within your organisation, you have flexibility to set this upgrade date for all your sandbox environments.

Kaptio recommends that any in progress customisations in your SIT and UAT environments are deployed to production
before

Once you have the release available in your sandbox, you can start to execute your own Kaptio Release Readiness process:

Review the release notes.
Decide what features to enable (if applicable). By default, all new features are disabled and need to be reviewed and enabled by your Salesforce Team. This ensures that you have a way to opt-in to new features and align carefully with your organisation for setup and training purposes. Enhancements, bug fixes and minor changes are usually enabled for all users automatically.
Create a regression test plan for any existing Kaptio/Salesforce customisations that are in your org.
Execute regression test plan and work with Kaptio Support to answer any questions related to the release.
Request the upgrade to be executed to your production org.

Although there is no strict time limit given, Kaptio urges clients to try and complete the process of upgrading your sandbox environments to finishing your production upgrade within a 2-week time frame.

In cases where you need to defer the initial upgrade of your sandbox environments, Kaptio recommends no more than a 2 month delay, otherwise you run into falling behind the release schedule with your upgrades.

There are risks associated with a major upgrade related to the testing of any customisations, extensions and integrations done to your Salesforce org. As an example, almost all Kaptio clients tend to have integrations with a Payment Gateway and Kaptio recommends testing this type of integration as part of each major release to ensure that the functionality works as intended and is not impacted by new features and functionality. Other areas include:

Financial system integrations, for example Accounts Payable/Accounts Receivable purposes.
External client documents, especially retesting actions such as “Ready to Book” and “Make Payments”.
Supplier workflow and external supplier pages.
Any custom extensions or pages built in and around the standard Kaptio Travel Platform workflow.

Kaptio recommends documenting regression test scripts for the areas of the system that contain customisations and executing manual regression testing by a professional tester for each major release.

Another common upgrade risk is related to the setup of profiles and permissions. Any new metadata (fields, objects etc) that are included in the release is highlighted in a dedicated section of the release notes. The standard Kaptio Permission Sets are automatically updated but Profiles or custom permission sets are not upgraded. In cases where you have setup your own Permission Sets, you will have to manually maintain them alongside your Profiles. Starting from Spring Major 2020, the release notes will provide recommendations on which new fields, objects and Visualforce pages need to be configured, with suggestions from Kaptio for the following groups of users that administrators should be able to tie back to their own Profiles & Permission Set setup: Integration Users, Itinerary Creators, Finance Users, Product Users, Content Users, External Docs Users.

Kaptio Minor Release Readiness

Kaptio chooses to deliver small increments of new features through our minor releases. Minor releases represent a small release containing a subset of features and improvements that are made generally available in a Major release. Minor releases are not made available to all customers.

Unlike Major releases, Minor releases are optional upgrades to your environment and only offered to selected customers. Minor releases are often used to introduce improvements or new features that tactically help with new customer go-lives and to assist with adoption and business change management. To learn more about our Minor releases, see our Minor Release Section on our Release Notes Portal.

For clients that are offered minor releases, the process is the same as for Major releases.

Kaptio Hotfix Readiness

Hotfix releases represent a release dedicated for fixes of critical bugs. A Hotfix is usually meant to fix an issue that was introduced in a minor or major release. As Kaptio releases are introduced using a staggered rollout approach, Hotfix releases do not usually affect all customers. To learn more about our Hotfix releases, see our Hotfix Release Section on our Release Notes Portal.

Kaptio recommends a more lightweight process around Hotfix releases compared to Major/Minor releases. The nature of a Hotfix is that it only affects specific areas of the system, and therefore full regression testing should not be required unless the bug fix is related to a specific customisation area. Kaptio recommends reviewing the steps for your major release process and deciding on which steps to take for your Hotfix releases. We recommend that you do this on a case-by-case basis, and working closely with the Kaptio Support team.

Deploying Customisations

The Kaptio Support team may be required to work on a ticket resolution that requires a change in your customization or a reconfiguration of your system. Depending on the complexity of this change (for example, change in code [complex] vs change in page layout [easy]), our team might have to get hand-on in resolving the problem within your environments and also provide assistance in deploying the change into your production environment. The general process that our Support team follows is detailed below.

Pre-Requisites Conditions

The conditions for Kaptio getting involved in working on a ticket that requires a custom deployment are:

The custom functionality was fully or partially developed by the Kaptio team in the past. If we were never involved in the development of the customization, Kaptio can only provide a supporting role where precise technical questions will be answered by our Support team.
The development activities have been agreed by Kaptio’s Technical Design Authority (TDA), as requested by 2nd level support.
A Kaptio Account Executive has been notified about our involvement in the issue resolution.
An issue related to the functionality has been escalated to 2nd Level Support where a thorough technical investigation has been completed with clear development investigation steps or development action.

Development & Deployment Process

If the conditions above are met, the ticket will go into a Development Backlog where our Development team will take action. Assuming you are following the Kaptio recommended Environment Model, the work will be executed and QA’d in a developer sandbox, and then a change set is prepared for the work and that change set is validated against your full copy sandbox UAT environment. The Kaptio Release Manager is then notified when this Deployment Change Set is ready for review, where the following steps will then take place:

Kaptio Release Manager will analyze the content of the Change Set and ensure that there is clarity on the content of change set, ensure that we have provided a description that will act as release notes for this deployment, and that any pre or post-deployment steps are considered and documented in the change set description. He will also ensure that the change set has been validated against the client’s full copy sandbox and production instance. For more information on Change Set validation, see this Salesforce help article
Once the Release Manager has validated the change set, he will notify our Support team to reach out to the customer with steps on how to test and deploy the changes.
The customer can now test the functionality. We strongly encourage all our clients to follow the Environment Model described in this guide and that any Release Testing is done on a . If there are any queries related to the testing phase, our Support team will assist in providing any information to help validate the fix.

newly refreshed Full Copy Sandbox

Once the customer has successfully tested the functionality, he can navigate to the Inbound Change Set section of his Production org where he can view all the related information about the change set as prepared by the Kaptio Development team and Release Manager. Once ready, the customer can choose to deploy the change set into production.

Deploying Change Sets into Production: Best Practices

Because our development team will validate the change set prior to your deployment, we don’t expect there to be any delays in the deployment or any errors (such as unit test failures, or component dependency errors). However, this cannot be guaranteed, especially if the change set has been waiting in the deployment queue for a long period of time. Kaptio recommends testing and deploying a change set within 14 days of the change set being validated.
You are required to fully test the functionality in your Sandbox prior to production deployment. Kaptio urges you to do this on a newly refreshed full copy sandbox, which ideally is running the same version of Kaptio and Salesforce as your production environment. Please do not deploy any change set into production until you have validated the functionality in your Sandbox environment.
If the Change Set needs to be updated/changed, please notify our support team who will then coordinate with our Release Manager to provide an updated change set.
The Kaptio team will only include the System Admin profile in the deployment Change Set. As our Development and Support team will not be familiar with the detailed setup of your profiles and permission sets, you will be responsible for identifying if changes in any other profiles/permission sets are required. If you want us to add additional profiles/permission sets, please notify the support team with a precise list of requirements.

Regression Testing

Kaptio strongly recommends having clearly defined acceptance criteria for all customisation work done on your org. This makes it easier to execute regression testing for your deployments and Kaptio upgrades. For testing teams that have experience with automated testing, Kaptio recommends 3rd party testing toolkits from TestCraft or Provar.

This guide outlines key articles to guide you through managing your environment effectively.

Data & Storage Management

Keeping your data safe and organized is essential for an efficient system. Learn about data and storage management in Salesforce with this article:

Salesforce Data & Storage Management

Supported Browsers

Finally, ensure you're using a supported browser to avoid technical issues. Check out the list of supported browsers:

Supported Browsers for Kaptio Travel

This guide should provide you with a solid foundation for managing your Kaptio Travel environment. Happy onboarding!

On this page

Delivery Lifecycle Roles & Responsibilities
Sandbox Data Seeding
Kaptio Core API Provisioning
Data Masking
Email Deliverability
Tracking Changes & Source Control
Environments Model
Deployment Tools
Kaptio Major Release Readiness
Kaptio Minor Release Readiness
Kaptio Hotfix Readiness
Deploying Customisations
Pre-Requisites Conditions
Development & Deployment Process
Deploying Change Sets into Production: Best Practices
Regression Testing
Data & Storage Management
Supported Browsers

Delivery Lifecycle Roles & Responsibilities
Sandbox Data Seeding
Kaptio Core API Provisioning
Data Masking
Email Deliverability
Tracking Changes & Source Control
Environments Model
Deployment Tools
Kaptio Major Release Readiness
Kaptio Minor Release Readiness
Kaptio Hotfix Readiness
Deploying Customisations
Pre-Requisites Conditions
Development & Deployment Process
Deploying Change Sets into Production: Best Practices
Regression Testing
Data & Storage Management
Supported Browsers