A guest walks up to a hotel front desk. They never received their booking confirmation. The front desk agent pulls up their screen — but they don’t have Salesforce access. They can’t trigger a resend. They raise a support ticket. The guest stands there waiting. It’s not a great experience.

This was the real-world problem a hospitality client brought to us. They had a robust Marketing Cloud setup with journeys for confirmation emails, pre-arrival messages, and post-stay follow-ups — all API-triggered via Salesforce CRM. The technical infrastructure worked. The access model didn’t.

The solution: a secure Marketing Cloud Cloud Page that gives front desk staff a simple portal to search for a guest and resend any email — without needing a single Salesforce or Marketing Cloud license.

In hospitality, a missing confirmation email is not a minor inconvenience — it’s the guest’s proof of reservation. Front desk staff need the power to fix it immediately.

Why Salesforce Licenses Aren’t the Answer

The first instinct is obvious: just give front desk staff Salesforce access. But a hotel chain with 20 properties and hundreds of front desk agents faces a cost and governance problem immediately. Salesforce licenses aren’t cheap, and more importantly, giving operational front desk staff access to the full CRM creates data exposure risk that most enterprise IT teams won’t approve.

What front desk staff actually need is extremely narrow: search for a guest, select an email type, press send. That’s a one-page tool — not a full CRM platform.

Architecture: What We Built

The solution has three components that work together: a Marketing Cloud Cloud Page as the front-end portal, Okta SSO for authentication, and existing Marketing Cloud API-triggered journeys as the email sending mechanism.

Component 1: The Cloud Page Portal

The Cloud Page is a single-page HTML/JavaScript application hosted natively on Marketing Cloud. It presents front desk staff with:

1. A search field to look up a guest by email address or booking confirmation number.
2. A results panel showing matching reservations.
3. A selection of email types (Booking Confirmation, Pre-Arrival, Post-Stay, etc.) rendered as buttons.
4. A send trigger that calls the existing Marketing Cloud journey API event.

The journeys themselves already existed and were already API-ready — built for Salesforce button triggers. The Cloud Page simply replaces the Salesforce button as the interface, calling the same underlying API.

// Call Marketing Cloud REST API to fire the journey event
async function triggerEmail(subscriberKey, emailType) {
  const payload = {
    ContactKey: subscriberKey,
    EventDefinitionKey: `hotel_resend_${emailType}`,
    Data: { ResendTriggeredBy: "FrontDesk" }
  };

  const response = await fetch(
    "/rest/journeys/v1/events", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify(payload)
    }
  );
  return response.ok;
}

Component 2: Okta Single Sign-On

Securing a Cloud Page is non-trivial because they run entirely on the front end — there’s no server-side session management. We integrated Okta, which this client was already using across their property management system and other internal tools.

Okta provides an SDK package specifically compatible with Salesforce Marketing Cloud Pages. The flow is simple: a staff member visits the Cloud Page URL, they are redirected to the Okta login screen for a few seconds, and then they’re returned to the same Cloud Page URL with a valid session token. The URL doesn’t change from the user’s perspective.

Okta SSO integration means front desk staff use the same credentials they already use for the PMS — no new passwords, no new accounts.

Component 3: Security Controls

Beyond authentication, the Cloud Page included several security measures appropriate for a shared-device front desk environment:

Idle timeout — the session automatically expires after a defined period of inactivity. A staff member who walks away from the terminal won’t leave an open portal for the next person.

Role-limited provisioning — only staff members explicitly provisioned in Okta with access to this application could log in. The provisioning was managed by the client’s IT team using their existing Okta workflows.

No data storage — all guest lookups are real-time queries against Marketing Cloud Data Extensions. The Cloud Page itself stores nothing, so there’s no local data exposure risk.

Frequently Asked Questions