Template Builder Guide

Design branded Apple Wallet and Google Wallet passes without code: layout, fields, images, barcodes, expiry rules, and template lifecycle management across orgs.

Builder basics

• Build in the Kemicard Templates tab; sample records drive the live preview and the associated object is displayed on each template.
• Display Header Field is required on every template.
• One template renders to both wallets — Apple as a signed .pkpass, Google as a JWT-signed object.
• Template count per org is a licensing control; contact support to raise it.

Multiple templates & tier switching

Create one template per membership level, event type, or campaign. A pass switches templates in real time when the assignment on the record changes — the standard pattern for tier upgrades, seasonal designs, and error states:

Flow: WHEN Member_Track__c changes to "Premium"
  → Kemicard Switch Template → "Premium Member Card"

• Clone — duplicate a template for per-tier variants; change images and colors only.
• Import/export — the standard path for promoting templates from sandbox to production, or across business units.

Images & dynamic thumbnails

• Dynamic thumbnails — per-record images (member photo, tier art) with API control; supported on Apple and Google (Google requires v2.28+).
• Strip image refresh — update the template strip image to promote a sale; installed passes refresh automatically via a record-trigger flow.
• Secure private images — serve member photos securely on Google Wallet rather than from public URLs; enable per template. For URL-based personal photos, consider privacy law before using publicly reachable links.
• Google image placement — image module placement affects rendering when secure images are enabled; compare before/after payloads if fields render oddly.

Back-of-pass fields & data detection

• Add rich back-of-card content with tappable links to payment, support, or scheduling pages.
• Apple applies default data detection when detector types are omitted; Kemicard supports URL, Phone, and Email detectors. Suppress detection when values get misread (e.g., a membership number rendered as a phone number).
• Google auto-detects from prefixes: https://, tel:, mailto:.
• Back-field content over 255 characters is validated by the builder.

Barcodes

• QR is the default recommendation — reliable on both platforms and with the Kemicard Scanner.
• PDF417 — use when you want a 1-D barcode look; scans reliably on Apple and Google passes.
• Code-128 is not recommended — it is not reliably recognized by common scanner libraries.

Expiry & relevant dates

• Set Expiry Date (fixed) or Relative Date (from enrollment) in Configuration; expired passes move to the wallet's expired section automatically.
• Always set a relevant date on event tickets: Apple Wallet can archive event passes older than a year that have none. Pushing any update to an archived card restores it.
• If expiry dates look wrong, audit the upstream data pipeline (forms, batch jobs, manual entry) before suspecting the package.

Multi-language & RTL

Create one template per language and assign by a language field on the record — proven in production including Arabic-market deployments. Test RTL layouts (Arabic, Hebrew) on physical devices; treat on-device layout QA as mandatory. Native multi-language support is on the roadmap.

Template design best practices

• Design for the lock screen first. The header and primary field are what members see most — put the brand and the member's name there, not internal codes.
• Keep labels short and uppercase. Wallet UIs truncate long labels; MEMBER ID beats "Membership Identification Number".
• One template per audience, cloned from a master. Build your base design once, clone per tier, and change only colors and images — updates stay consistent.
• Contrast-check both platforms. Apple renders slightly darker than the builder preview; Google applies its own field layout. Validate on physical devices before rollout.
• Reserve the back of the pass for action. Renewal links, support contact, referral pages — every back field is a Salesforce field you can update without a reissue.
• Name templates for members, not admins. The pass display name combines template and record names, so "Gold Member Card" beats "TMPL_GOLD_V3_FINAL".
• Plan the error state. Create a revoked/duplicate-detected template up front so security workflows have somewhere to switch a compromised pass.

Field mapping reference