The customer administrator runbook for production: installing the Kemicard package in a production org, migrating your validated sandbox configuration across, and upgrading an existing production org that runs an older version of Kemicard.
Who implements? Your internal Salesforce admin can follow this runbook end to end — or hand it to any of our SI partners or the Kemisoft Professional Services team.
Part A — Installing Kemicard in Production
This part details the formal process for deploying Kemicard into a Salesforce Production environment, using Salesforce-native pathways to ensure configuration integrity.
Phase 1 — Pre-installation & prerequisites
Before initiating installation, verify that the following prerequisites are met to prevent integration failures.
1.1 Environment readiness
- Administrator access — ensure you have the System Administrator profile in the target production org.
1.2 Org detail provisioning
Critical: you must request API credentials from Kemisoft before proceeding to Phase 2. Send the following details to Kemisoft:
- Production Org ID.
- The specific username designated as the integration user.
Phase 2 — Configuration & package installation
2.1 Install the managed package
- Access the production install URL: navigate to install.kemicard.app/products/kcard/latest.
- Click “Install Package Only (New Installs or Upgrades)”.
- Click the “Login into Start Pre-Install Validation” dropdown and select the appropriate org.
- Log in as a Salesforce administrator.
- Select Install for All Users and click Install.
- When prompted to Approve Third-Party Access, check “Yes, grant access to these third-party web sites” and click Continue.
- Wait for the installation process to complete.
Verify the installed version matches the version shown on the installation page under Setup → Installed Packages.
2.2 Configure named credentials
- Navigate to Setup → Named Credentials.
- Edit the Kemicard App entry.
- Input the Username and Password provisioned by Kemisoft (from step 1.2).
2.3 Authorize the Kemicard user
- Open Kemicard from the App Launcher.
- In the Kemicard Console, select Authentication.
- Click Authorize Kemicard User and select Allow in the Salesforce popup.
- After successful authorization, you should see the authenticated integration user displayed.
Phase 3 — Migration & order of execution
Rule: migrate metadata first via Change Sets, then designs via Export/Import. Templates rely on existing fields.
Kemicard itself needs only two lookup fields on the object you issue passes from (to Kemicard Pass and to Kemicard Template Pass), plus the Kemicard Configuration V2 record that names them. Everything else is your own setup. For exactly what goes in the change set, with passes on Contact and on a custom object, see Migration Examples.
3.1 Metadata migration (Change Sets)
- In sandbox: create an Outbound Change Set.
- Add the two Kemicard lookup fields (e.g.,
Membership_Pass__candMembership_Pass_Template__c) and the Kemicard Configuration V2 custom metadata record. Then add your own supporting metadata: the email, date and wallet URL fields, the flows that send and scan passes, the button, the page layout or Lightning record page, email templates, and the permission set that grants access to the fields. - Validate the change set in production, then deploy it via Inbound Change Sets. The lookups point at Kemicard objects, so validation fails unless the package is already installed on the same version as the sandbox.
- Activate the flows if they arrived inactive, and assign the permission set to the people who send or view passes.
Fields created by the configuration wizard have no field-level security, not even for System Administrators. Include a permission set that grants Read and Edit on them in the change set, or users won't see the fields and passes may not be linked to records.
3.2 Template migration (Export/Import)
- In the sandbox, open the Template Workbench (from a template, or its tab) and Export. You get one JSON file with the templates and their configurations.
- In production, after the change set is deployed, drop the file on the Template Workbench, choose the templates and Review & Import. Pass templates are records, so change sets can't carry them.
Watch it done: Kemicard Template Import/Export — video walkthrough.
Phase 4 — Post-migration validation
Conduct the following functional tests to sign off on the production environment.
- Version — Setup › Installed Packages shows the same Kemicard version as the sandbox.
- Integrity check — verify Named Credentials show a status of “Authorized”, and Kemicard Console › Authorization shows the authorized user.
- Configuration — the Kemicard configuration record is Active and names the right fields (open it with Edit, then cancel without saving).
- Flows and templates — the flows are Active, and the imported templates are Active on the Kemicard Templates tab.
- Custom permission sets — assign custom permissions to users depending on their role.
- Pass generation — pick a sample record and generate a digital pass. The pass lookup on the record fills in and the email arrives.
- Rendering — confirm branding and QR codes appear correctly in Apple Wallet and Google Wallet.
- Flow execution — scan a pass with the Kemicard Scanner to ensure the scan flow triggers.
Part B — Upgrading an Existing Production Org
This part covers upgrading an existing Salesforce production org that is running an older version of Kemicard to the latest release.
- Test in sandbox first — the new version should be tested in a sandbox before upgrading production.
- Administrator access — System Administrator profile in the production org.
Upgrade the package
Use the same installer as Part A: open install.kemicard.app/products/kcard/latest, choose “Install Package Only (New Installs or Upgrades)”, log into the production org, and complete the installation. Verify the new version under Setup → Installed Packages.
Apply package updates (Kemicard Console → Updates)
Required from release 2.28 onward. Installing or upgrading the package does not, by itself, apply all of Kemicard's metadata and schema changes for the new version. After the package upgrade you must run the upgrade steps from the Console so they execute under your active administrator session — this avoids Salesforce's post-installation restrictions. You do this yourself; it does not need a support case.
- In the Kemicard Console, open the Upgrades area. From v2.29 the nav item carries a Pending badge when steps are outstanding, so you can see an upgrade is due without opening the panel.
- The Updates card on the right shows your Current Version and a What's New link.
- If the System Upgrades panel shows “Upgrade Pending”, click Run Upgrade. The button is disabled while running — let it complete.
- Confirm every step in Last Upgrade Run Results succeeded; a successful run shows “System is Up to Date”.
Upgrading to 2.30? The upgrade steps add the Update & Notify request type and the None data detector option, record whether the org is a sandbox, schedule the daily connection check (2:00 AM), and prepare the Kemicard Connect scheduler. Afterwards, check Console › Connect Scheduler shows Active. The users who run upgrades need the Kemicard Digital Pass permission set, which now includes the Kemicard Upgrade Access custom permission. Kemicard Connect replaces Campaign Manager, and existing Campaign Manager permission set assignments carry over. Full details in the 2.30 release notes.
Do not skip this step on an upgrade (e.g., 2.28 → 2.29). Until “System is Up to Date” is shown, the org is running on incomplete metadata and passes may not generate correctly.
After upgrading, re-run the Phase 4 validation checks above.
Sources: Salesforce Help: Install a Managed Package; Named Credentials; Change Sets.
Where to go next
- Kemicard Connect — roll passes out to your full production base, now or on a schedule.
- Release notes — what changed in the version you just installed.
- Troubleshooting & KB — including named-credential status-code diagnosis.
