Greenfield Salesforce Org Provisioning for Kaptio

Overview

Use this guide when a customer is starting Kaptio without an existing Salesforce org. It gives delivery consultants and customer IT teams a shared sequence from the licensing decision through to a usable set of connected environments.

This is an implementation coordination guide, not a replacement for Salesforce administration, security review, or the detailed Kaptio foundation configuration. Use the linked guides for currency, tax, channels, users, and deployment governance.

Greenfield means a real customer org

A greenfield implementation starts with a new production Salesforce org that will become the customer’s system of record. It is different from:

Org type	Appropriate use	Provisioning implication
Customer production org	The permanent live Kaptio environment	Contracted, governed, backed by the required licenses, and used as the source for customer sandboxes
Sandbox	Implementation, integration testing, acceptance, and training	Created from the customer’s production org; refresh and expiry behaviour depend on the Salesforce entitlement and sandbox type
Demo or trial org	Short demonstrations and early evaluation	Not a substitute for the permanent customer org; may expire or lack the final license and environment model
Scratch org	Temporary developer work	Time-limited and not suitable as the customer’s production foundation

Do not begin customer configuration in a demo, trial, or scratch org with the intention of turning it into production later.

Stage 1: Confirm the Licensing Route

Resolve the commercial and Salesforce licensing route before anyone creates an org.

Route	Usually fits	What must be agreed
Kaptio OEM model	The customer does not already use Salesforce and wants a single relationship with Kaptio	Included platform licenses, required full Salesforce licenses, user quantities, storage, API allocation, and sandbox entitlement
ISV model with customer Salesforce licenses	The customer will hold a direct Salesforce relationship or needs Sales Cloud or Service Cloud capabilities	Salesforce edition and licenses, Kaptio licenses, org ownership, sandbox entitlement, and responsibility for Salesforce support

For the detailed comparison, read the Kaptio CRM & Salesforce Licensing Guide.

Decision record

Before progressing, record:

Licensing route: OEM or ISV
Contracting party responsible for Salesforce licensing
Required user license types and quantities
At least one full Salesforce license for the KTAPI sync user
Required sandbox types and quantities
Production org owner and named customer Salesforce administrator
Kaptio commercial and delivery contacts

Stage 2: Provision the Production Org

The production org is created first. Sandboxes are then provisioned from that customer org according to the agreed environment strategy.

Kaptio and customer actions

Confirm that the customer name, legal entity, billing contacts, data residency requirements, and primary administrator are correct.
Complete the agreed OEM or Salesforce ordering process.
Create the permanent production org and capture its Salesforce Org ID.
Register the customer and org through the applicable Kaptio license-management process.
Assign named administrators; avoid shared credentials except for a documented break-glass account.
Confirm the org’s edition, licenses, storage, API limits, and sandbox entitlements against the agreement.
Record the org owner, recovery contacts, MFA/SSO plan, and support route in the implementation record.

Production-org gate

Do not install or configure Kaptio until:

The permanent production Org ID is recorded
A named customer administrator can log in
Kaptio has the approved support and installation access
License quantities and sandbox entitlements are confirmed
Security ownership and the access-review process are agreed

Stage 3: Install Kaptio Travel

Kaptio Travel is supplied as a managed package installed into the customer-owned Salesforce org.

Installation sequence

Agree the supported Kaptio Travel version and installation window with the Kaptio delivery team.
Confirm that the installing administrator has the required Salesforce access.
Install Kaptio Travel in the production org using the approved package link and Kaptio release instructions.
Verify the installed package name, namespace, version, and license allocation in Salesforce Setup.
Assign the minimum administrator access needed to continue provisioning.
Record the installed version and installation result in the implementation record.

Use Installed Packages, the License Management App, or the KTAPI dashboard as the verified source for the installed Kaptio Travel version.

Installation validation

Kaptio Travel appears in Installed Packages
The installed version matches the approved version
Package licenses are allocated as planned
A named administrator can open the Kaptio app
Installation warnings or failures are recorded and resolved before sandbox creation

Stage 4: Create the Environment Map

Agree the purpose, owner, data policy, and promotion gate for each environment before creating sandboxes.

One-page environment map

Environment	Typical owner	Purpose	Data approach	Exit gate
Development sandbox	Kaptio	Initial configuration and approved development	Template and synthetic test data	Configuration is ready for QA
QA sandbox	Kaptio	Kaptio validation and deployment rehearsal	Promoted configuration plus synthetic test data	Kaptio test evidence is accepted
SIT sandbox	Customer, supported by Kaptio	End-to-end integration and story testing	Controlled integration test data	Integrations and agreed scenarios pass
UAT sandbox	Customer	Business acceptance, training, and cutover rehearsal	Representative, approved test data	Customer signs off go-live readiness
Production	Customer	Live operations	Governed production data	Go-live approval and cutover complete

Smaller programmes may combine development and QA, but SIT and UAT must retain distinct purposes and sign-off criteria. Confirm the actual sandbox types against the customer’s Salesforce entitlement.

For refreshes, promotion gates, deployment tooling, and environment governance, use Deployment Pipeline & Environments.

Username convention

Use a consistent username pattern that identifies the person and environment:

{email}.{orgname}

For example, alex@example.com in an org named alexanderroberts-uat becomes alex@example.com.alexanderroberts-uat.

Keep the person’s real email address in the Salesforce email field. Do not create generic shared users for normal delivery or testing.

Environment record

For every org, capture:

Org name, Org ID, and environment purpose
Sandbox type and refresh eligibility
Named Kaptio owner and customer owner
Administrator and test-user usernames
Data classification and approved test-data source
Connected third-party systems
Source and target in the promotion path
Entry criteria, exit criteria, and approver

Stage 5: Establish the Kaptio Foundation

Once the environments exist, configure the organizational and financial foundation in the lowest agreed environment and promote it through the pipeline.

The foundation normally includes:

Business Units and Sales Channels
Currencies, exchange rates, and tax handling
Booking-number schemes
Users, roles, profiles, permission sets, and Business Unit access
Initial reference and test data

Do not duplicate those configuration decisions in the provisioning record. Use Your Kaptio Foundation and its linked implementation guides as the source of truth.

Foundation gate

The foundation design has customer approval
Named admin and test users exist in each environment
Permission assignments match the agreed roles
Foundation configuration has been promoted, not rebuilt manually
A basic test itinerary can be created and saved

Stage 6: Connect Kaptio Cloud Services

An installed Salesforce package is not yet a usable Kaptio environment. Connect only the services included in the customer’s scope, and configure each environment against the matching non-production or production service.

Service	What is connected	Kaptio responsibility	Customer responsibility	Minimum verification
KTAPI	Salesforce org, API client, sync user, and required endpoints	Create or register the client, configure protected package settings through the approved process, and activate the required sync	Provide approved admin access and the licensed sync user; confirm intended data scope	Authentication succeeds and an agreed sample record synchronizes
Edge Documents	Document service, Salesforce access, storage/email endpoints, and customer templates	Configure the service connection and agreed template baseline	Provide approved branding, content, sender details, and business sign-off	Generate, open, and send an agreed test document
Kaptio Pay	Payment service, gateway account, Salesforce configuration, and environment-specific credentials	Configure the Kaptio integration and support end-to-end validation	Own or authorize the payment-provider account, supply credentials through the approved secret-sharing process, and approve payment rules	Complete an approved test payment and verify the Salesforce transaction result

Protected package endpoints require a Kaptio-managed setup process and may require License Management App access. Package installation alone does not prove that endpoints or cloud services are configured.

Never paste credentials, tokens, payment secrets, or protected endpoint values into the implementation checklist.

Connection checklist for every environment

The service endpoint matches the environment
Named service users have the correct license and least-privilege access
Credentials were transferred through the approved secure process
Salesforce remote access settings required by the service are present
Connectivity has been tested
One end-to-end business scenario has passed
The owner, result, and test date are recorded
Sandbox refresh and credential-rotation steps are documented

Who Does What

Use this as the starting ownership split and adjust it in the project plan where the contract says otherwise.

Activity	Kaptio	Customer
Confirm Kaptio commercial model and package entitlement	Accountable	Consulted
Procure or authorize Salesforce licenses	Supports for OEM	Accountable for direct Salesforce relationship
Name the production org owner and customer administrators	Consulted	Accountable
Register the customer in Kaptio license management	Accountable	Provides required details
Install and verify Kaptio Travel	Leads with approved access	Approves access and installation window
Provision customer Salesforce sandboxes	Advises on pattern	Accountable
Define environment purpose, ownership, and gates	Joint	Joint
Configure Kaptio foundation	Leads during implementation	Reviews and approves
Provide identity, network, branding, gateway, and integration inputs	Advises	Accountable
Configure Kaptio-managed cloud connections	Accountable	Provides approved access and inputs
Execute SIT and UAT sign-off	Supports	Accountable
Maintain production governance after go-live	Supports under the agreed service	Accountable

Common Traps

Treating a demo org as the customer foundation

Demo, trial, Developer Edition, and scratch orgs are useful for evaluation but are not the contracted production org. Starting implementation there creates avoidable rework and may leave the programme without the right licenses, sandboxes, support relationship, or permanent Org ID.

Assuming sandboxes are permanent and identical

Sandbox type, storage, refresh interval, and expiry behaviour depend on the Salesforce entitlement. After a refresh, usernames, endpoints, credentials, connected apps, and integrations may need review or reconnection.

Rebuilding configuration in every environment

Manual rebuilding causes drift. Establish a controlled promotion path and use the project’s deployment and data-seeding tooling.

Assuming package installation connects everything

The managed package, KTAPI, documents, payments, and optional integrations have separate setup and verification steps. Mark each connection complete only after its end-to-end test passes.

Applying a greenfield checklist to an existing Salesforce org

An existing org requires an impact assessment for current objects, automation, security, integrations, data volumes, governor-limit usage, and release governance before installation. That assessment is outside this greenfield walkthrough.

Copy-Paste Programme Checklist

Commercial and ownership

OEM or ISV licensing route approved
Salesforce and Kaptio license quantities confirmed
Sandbox entitlement confirmed
Customer org owner and Salesforce administrator named
Kaptio account, delivery, and technical owners named

Production org and package

Permanent production org provisioned
Production Org ID recorded
Customer registered in the applicable Kaptio license-management process
Approved Kaptio Travel version installed and verified
Package licenses assigned

Environments and users

Development, QA, SIT, UAT, and Production map agreed
Required sandboxes provisioned
Purpose, owner, data policy, and gate recorded for each environment
Username convention applied
Named admin and test users created
Refresh and promotion process documented

Kaptio foundation

Business Units and Sales Channels approved
Currency, tax, and booking-number configuration approved
Roles, profiles, permission sets, and user access tested
Foundation promoted through the agreed pipeline

Cloud services

KTAPI client, sync user, endpoints, and synchronization verified
Edge Documents connection and test document verified, if in scope
Kaptio Pay gateway connection and test transaction verified, if in scope
Optional integrations connected and tested
Credentials excluded from project documents
Reconnection steps documented for sandbox refreshes

Readiness and handover

SIT exit criteria passed
UAT sign-off recorded
Production cutover and rollback plan approved
Support contacts and escalation route shared
Environment and integration ownership handed over

You’re Ready When

The programme is ready to move from provisioning into implementation when:

The permanent production org and required sandboxes exist.
Kaptio Travel is installed at a verified, approved version.
Every environment has a named purpose, owner, data policy, and promotion gate.
Named users can log in with the right access.
Foundation configuration can be promoted through the environment path.
Every in-scope cloud service has passed an end-to-end test.
The customer and Kaptio have recorded ownership for refreshes, releases, credentials, and support.