Kemicard – Apple and Google Wallet Cards for Salesforce

PO Box 55056 RPO Windermere, Edmonton AB T6W 5B4

+1-780-237-2142

Follow Us On:
Powered by: KEMISOFT
View Categories

Wallet Core Features

5 min read

1. Generating passes from Salesforce and adding to iOS/Android device (Apple & Google Wallet)

What users can add

  • Membership or donor cards (e.g., “2026 Supporting Member”).
  • Loyalty or discount cards tied to Accounts, Contacts, or custom objects.
  • Event tickets, badges, or permits generated from a Campaign, Event, or custom record.

From a Salesforce record (Contact / Custom Object)

  1. Open the relevant record in Salesforce
    • Example: Contact, Account, or a custom “Member__c” or “Pass Holder__c” object.
  2. Confirm Membership Pass  Template is added to the contact/custom object.
  3. Click Generate Pass (or equivalent)
    • Salesforce creates a digital pass instance linked to that record (Apple and/or Google format).
    • Based on template configuration and/or automation an email or SMS could be sent to the customer.

User steps on the device

  1. Open the email or SMS received from your organization.
  2. Tap Add to Apple Wallet or Save to Google Wallet.
  3. Preview the pass (name, ID, expiry, barcode, branding).
  4. Tap Add. The pass is now visible in the user’s Wallet and stays linked to the Salesforce record for live updates.

Example: A nonprofit creates a Member__c record for Jennifer; a Kemicard pass is generated and sent automatically after approval, and Jennifer taps the email button to add it to her Apple or Google Wallet.


2. Updating and revoking passes (removing or changing items)

Automatic updates from Salesforce

  • Any change to the linked Salesforce record (tier, points, expiry date, status) can push a live update to the existing pass; the user does not need to re-add it.
  • Common updates include:
    • Upgrading/downgrading membership tier
    • Extending expiry dates after renewal
    • Updating event details (time, venue, seating)
    • Changing permit status (approved, pending, revoked)

Example: A member renews, and the Membership_Status__c is set to “Active” with a new expiry date; the Kemicard pass refreshes automatically with the updated status and date in the Wallet.

Revoking a pass from Salesforce (admin)

  1. Open the underlying object record in Salesforce.
  2. Locate the Kemicard-related fields or child object representing the pass instance (e.g., “Kemicard Pass” record).
  3. Change the status to a non-usable state (for example, “Cancelled”, “Expired”, or “Revoked”) or use a dedicated Revoke Pass action if configured.
  4. Save the record. Kemicard sends an update to mark the pass invalid or remove key functionality (barcode no longer scans, clear “Valid” indicators, etc.).

Removing a pass from Wallet (end user)

  • From Apple/Google Wallet, users can:
    • Open the pass, tap the More or menu icon, then choose Remove Pass / Remove from Wallet and confirm.
  • Even if the user doesn’t manually remove the pass, a revoked or expired pass can be visually marked as no longer valid through a backend status update.

Example: An organization revokes a lapsed membership by setting Status__c = “Lapsed”; the Kemicard pass updates to show “Expired” and can be safely removed by the user from their wallet app.


3. Using Kemicard passes in daily workflows

Check‑in and verification at physical locations

  • Scanning a barcode or QR code:
    • Staff scan the barcode/QR on the Kemicard pass using a scanner or POS device to verify identity, membership, or ticket validity.
  • Supported scenarios:
    • Nonprofit membership check-in
    • Retail loyalty redemption
    • Event access control
    • Government permits or licenses shown at checkpoints

Example: At an event, attendees present their Kemicard pass at the door; staff scan the QR code, and Salesforce updates an “Attended__c” flag on the corresponding Contact or Event Registration record.

Trigger-based issuance and updates

  • Kemicard is native to Salesforce, so you can use Flows, or Apex to:
    • Auto‑issue a pass when a record reaches a specific stage (e.g., “Approved”).
    • Auto‑update pass fields when related data changes (e.g., points balance, membership tier, permit validity date).
  • This turns day-to-day CRM events into Wallet actions without extra integrations.

Example: When an Opportunity of type “Membership Sale” is closed-won, a Flow creates a Membership__c record and automatically issues a Kemicard pass to the Contact, emailing the Wallet links.

Communication and engagement

  • Passes can carry dynamic text fields used for short announcements like “Renew now”, “Event moved to Room B”, or “New discount available”.
  • When you change these text fields in Salesforce, the pass updates and effectively becomes a micro-notification channel in the user’s wallet.

Example: Before an event, you update a Pass_Field_Content__c(Name) field with “Doors open 6:30 PM”; attendees see the updated message directly on their pass without any new email(Push Notification).


4. Security and privacy basics with Kemicard

Architecture and data location

  • Kemicard is built 100% native on Salesforce, so all member and pass data resides inside your Salesforce org, not in an external database.
  • Apple Wallet and Google Wallet hold only the pass representation and the fields you choose to surface; sensitive data can remain server-side in Salesforce.

Protection of data

  • Salesforce provides encryption, access control, and auditing for the underlying records (e.g., Contacts, Membership__c, Kemicard pass objects).
  • Apple and Google Wallet add device-level protections, including encryption, biometric/PIN access, and optional remote wipe if a device is lost or stolen.
  • You can restrict who can create, update, or revoke passes by using Salesforce profiles, permission sets, and field-level security on Kemicard-related components.

Example: Only users with a “Kemicard User” permission set can issue a pass, ensuring that front-line staff cannot accidentally issue or revoke passes.

Privacy and data minimization

  • You choose which fields appear on the pass: usually a name, membership/ticket ID, expiry date, and simple status, while more sensitive attributes stay in Salesforce only.
  • Organizational privacy and retention policies still apply; you can configure how long membership and pass records are retained and when they are archived or anonymized.

Example: A nonprofit shows only “First Name, Last Initial, Member ID, and Expiry” on the pass; donation history and contact details remain visible only to staff inside Salesforce.

Powered by BetterDocs