Enable Salesforce MFA / SAML session delegation

Configure and enable Salesforce SAML VF-session delegation so Visualforce pages load in the Skedulo mobile app under Salesforce MFA enforcement.

Overview

Salesforce enforces multi-factor authentication (MFA) for all interactive UI sessions. Skedulo Plus embeds Salesforce Visualforce pages (Timesheets, Shifts) inside the mobile app. Previously, the app opened these embedded pages using a session that Salesforce classifies as Standard Assurance. Under MFA enforcement, a Standard Assurance session triggers an interactive MFA challenge that the embedded page cannot complete, so the Visualforce page fails to load.

With Salesforce MFA delegation enabled, Skedulo signs the user in to Salesforce as a trusted SAML identity provider and asserts a High Assurance session. The result is a seamless, MFA-compliant session with no app update and no extra login step for your users.

Enabling a tenant has two independent gates, both required:

  • Regional master switch — managed by Skedulo and already ON in production across all regions. You do not need to do anything here.
  • Per-tenant setting — the Salesforce MFA delegation setting in the Skedulo web app. It defaults to off. This is the switch you turn on per tenant, and it is the last step below.

Prerequisites (per tenant)

  • The tenant is in a production region (US / AU / UK / CA).
  • The customer’s Salesforce org has My Domain enabled (nearly always already true for these orgs).
  • The customer’s Salesforce org actually enforces MFA org-wide — this is the basis for asserting a High Assurance session. Confirm before enabling.
  • You have a Salesforce administrator with access to Setup → Single Sign-On Settings.
  • You have a Skedulo user with the Administrator role, or a custom role granted the Manage Salesforce MFA delegation permission (see Part 3).
  • You know the tenant’s Salesforce Org ID (the same as the tenant’s Skedulo tenant ID).

How to verify the org enforces MFA

How you confirm this prerequisite depends on how the org’s users sign in — for these tenants it is almost always the SSO case:

  • SSO logins (typical here): users authenticate through the customer’s own identity provider (Azure AD, Okta, etc.), so MFA is enforced at that identity provider, not in Salesforce — Salesforce’s “Require MFA for all direct UI logins” setting does not govern SSO logins. Verification is therefore an attestation: have the customer’s identity-provider admin confirm MFA is required for the users who use Skedulo. (This is why Salesforce MFA delegation is an admin-set option — Skedulo cannot detect the upstream identity provider’s MFA.) Cross-check in Setup → Login History that those users’ logins arrive via the identity provider.
  • Direct username/password logins: in Salesforce go to Setup → Quick Find → Identity Verification and confirm “Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org” is enabled. From the June 2026 release this is permanently on and can no longer be disabled. MFA can also be enforced per user via a permission set or profile that grants the “Multi-Factor Authentication for User Interface Logins” permission.

Salesforce references: Enable MFA for your entire org · Use Salesforce MFA for SSO logins · Prepare for MFA enforcement for all employee users.

Part 1 — Configure Skedulo SSO in the Salesforce org

This creates a second, IdP-initiated-only SAML Single Sign-On setting with Skedulo as the identity provider. It sits alongside any existing customer identity provider (for example, Azure AD) and must not disturb normal staff logins.

Step 1.1 — Open Single Sign-On Settings

In the Salesforce org: Setup → Quick Find → Single Sign-On Settings → New (not “New from Metadata File”).

Step 1.2 — Fill in the SAML Single Sign-On Setting

Set the fields exactly as follows:

Field Value
Name Skedulo SSO
API Name Skedulo
Issuer https://auth.skedulo.com/saml
Entity ID https://saml.salesforce.com
Identity Provider Certificate Upload the Skedulo production public certificate (see Part 2). Save it to a .crt file and upload it here.
Request Signing Certificate Default
Request Signature Method RSA-SHA256
Assertion Decryption Certificate Assertion not encrypted
SAML Identity Type Assertion contains the Federation ID / Username of the user
SAML Identity Location Identity is in the NameIdentifier element of the Subject statement
Service Provider Initiated Request Binding HTTP POST (inert — no login URL is set)
Identity Provider Login URL LEAVE EMPTY
Custom Logout URL Leave empty
Custom Error URL Leave empty

Click Save.

Step 1.3 — Note the Login URL

After saving, confirm that Salesforce displays a Login URL for the new SSO setting — this confirms the setting saved correctly. You do not need to send this URL to Skedulo.

Step 1.4 — Do NOT enable it as a login option

Confirm all the following, so Skedulo’s identity provider stays scoped to the delegated Visualforce session only:

  • Under My Domain → Authentication Configuration, the Skedulo SSO setting is NOT ticked as an Authentication Service (it must not appear on the login page).
  • In the same My Domain → Authentication Configuration screen, confirm Skedulo is not selected as the default authentication service and has not been moved to the top of the Authentication Service order — the standard login form (or the customer’s incumbent identity provider) must remain the default. (Because Skedulo is left unticked in the item above it cannot become the default; this is a second confirmation.)
  • In Setup → Quick Find → Session Settings, review the Session Security Levels section and any Session Security Level Policies — confirm none references the Skedulo SSO setting/login and that no policy was added to raise or alter the org session level for it. (High Assurance comes from the assertion attributes, not from an org-global policy — this keeps the incumbent identity provider’s logins untouched.)

Step 1.5 — Multi-IdP coexistence check (if the org already has an identity provider)

Many of these orgs already run a third-party identity provider (Azure AD, Sage Portal, etc.). Skedulo’s Issuer https://auth.skedulo.com/saml is distinct from any incumbent Issuer, so Salesforce routes assertions by Issuer byte-match with no collision. Record the incumbent Issuer(s) in your notes so a future collision would be detectable.

Part 2 — Skedulo production SAML public certificate

Upload this exact certificate as the Identity Provider Certificate in Step 1.2. It is the same certificate for every production org (a single global signing identity). Copy the whole block, including the BEGIN/END lines, into a file named e.g. skedulo-saml-prod.crt.

Certificate details: Subject CN=Skedulo SAML IdP (prod), O=Skedulo · expires 2 July 2036.

-----BEGIN CERTIFICATE-----
MIIFczCCA1ugAwIBAgIUddhYSGnEqFWnEDZquJlInEquPG0wDQYJKoZIhvcNAQEL
BQAwNDEgMB4GA1UEAwwXU2tlZHVsbyBTQU1MIElkUCAocHJvZCkxEDAOBgNVBAoM
B1NrZWR1bG8wHhcNMjYwNzAyMDExNzU2WhcNMzYwNzAyMDExNzU2WjA0MSAwHgYD
VQQDDBdTa2VkdWxvIFNBTUwgSWRQIChwcm9kKTEQMA4GA1UECgwHU2tlZHVsbzCC
AiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAKQEzLwoLlKW59z14+ozpKVb
wHmJ+yKBmttm2/YcRU+pB6/W76fKyh5I9IQgnaGIO10blnAAPIi2lQ/Mtwxcy/NJ
uSoXzad6Ble/XH8aXUyeDM4y1cbFV+pt9kMDsAUvaiVivKc0jYia0s6sc+AnC4ej
fePznn4MIxoQBu8+9Kb2JsCALh4YlXnqyr32g/MIkaipkyaIsp46uKuDFf4bYT7f
mCb40qSSMdsXhLCHsRBbB1l1zoDdlpzZFRzx/jF9kQMvvEDguEevT9QvKtofyv9s
BQQW1OkF7mr5uydx7tgMiPI/zZiTQczN0YmMwB/VP4qfd/CneSv+3v+zou1kET6B
zqpJlVXuPeESMz1c0WV/G0R0PbMbjneEX7rcP6VW5PS11co6sK6S92lUb3mT2UM4
f8zdOJdvm9RQx9RSA0KTom3eJibv3e/BBQYKkXuugXkdff8S6Rwr7B66o/nIZUg6
nldRZBxWGko/A8Bn7P6H1bdIFoJFp5p60kTUBCKjPCY2Y4822BOy0WeBSAtnstL1
NITfweuzYYk7SaU4CcNEcp+OMkTpfcaaTseIhPzmXfnhoqgkCL1Ii4D4ubDmNF2P
ByhCyF13xrLy6PsQ67LizX3wi/6dWF/bo+3YFvc0QilhAPPRqCwiUyaSlckPhHg+
Hxji/lhuMApEd32Oz8tdAgMBAAGjfTB7MB0GA1UdDgQWBBQj+eV21FuxnhQHfPyu
jKCMIyWJhjAfBgNVHSMEGDAWgBQj+eV21FuxnhQHfPyujKCMIyWJhjAPBgNVHRMB
Af8EBTADAQH/MCgGA1UdEQQhMB+GHWh0dHBzOi8vYXV0aC5za2VkdWxvLmNvbS9z
YW1sMA0GCSqGSIb3DQEBCwUAA4ICAQCG3SV8quWGQb/u1rJrhtN6w+0enEHFDJsl
YXxfbNZx//bUsCPJ3H/0bOiNBZyCqesdVIYNvnr3vyrkQL7FIbROKfOBe61gBRvG
00ELlv1u66oii6lV6LMji8mpIDvXn4vAKcfMoFLndY5PymdIE3LyMPliQj2+GLKp
9NM7HKV8Hf4hETXY12nnXRI/rMu7OpKnVUvnn3R3Fy947SLlVrWJIuSekbFMIzhY
Rpq7J7joyr6vHzT+okDLy+Dn87vKgQ6mctWmOifpoTNck9CdkoOsQLa6iuQ00YZP
K3VIWTtxYCdJPI88OIh4FrlHg3NFxNQ2DyDbio0OCAQPHC7NOIj+HaG/WFLCTJlG
/pT/X2Gmp44iwstVW0VgdHMI65COIYQPiMYn7c8+ugGco9Qzqp9aGQznjra7SVuu
sOkGiuTKt0vzQGddOkOte4ECYLfZ2OXHlqSvd+Wq0+uIViY5jSjJ4TlG0KxrOWUb
7yykPHRQvN8iMPZ9iqtcGn3PYyJ3iR80siZsWX9cdTZW4x0wlIXNIsb4dPbWvhhk
00cqFcoOnbS3Ki88g2bKkNfMu/vLaTczOXv2rzDbVfuMrz5TvKuHc9SMJoIlq/TW
MNrWZzfRr4eo3gXHHlmNs4MDUCfNaWF2oPUxEsZQjB8OSG/6VjbTHDNPPE2++BqY
iLTqIkhUmA==
-----END CERTIFICATE-----

Part 3 — Enable Salesforce MFA delegation in the Skedulo web app

Do this only after Part 1 is complete and verified, and only after confirming the org actually enforces MFA org-wide. Skedulo asserts a High Assurance session only when this setting is enabled; turning it on activates delegation for the tenant.

Who can enable it

The Salesforce MFA delegation setting is controlled by a Skedulo user with either:

  • the Administrator role, or
  • a custom role granted the Manage Salesforce MFA delegation permission (skedulo.tenant.config.salesforceMfa.modify).

The setting is scoped to Salesforce and appears only on Salesforce-backed tenants. If you do not see it, confirm the tenant’s platform vendor is Salesforce and that your role carries the Administrator role or the permission above.

Steps

  1. Sign in to the Skedulo web app as an administrator (or as a user with the Manage Salesforce MFA delegation permission).
  2. Go to Settings → System administration → Salesforce MFA delegation.
  3. Read the high-impact warning on the page. It confirms this setting controls whether Salesforce Timesheets and Shifts load under Salesforce MFA enforcement.
  4. Turn the Salesforce MFA delegation toggle on.
  5. In the confirmation dialog, confirm that your Salesforce org enforces MFA org-wide. Enabling delegation asserts a High-Assurance session on your users’ behalf, so this confirmation is your attestation of the prerequisite above.

The change takes effect immediately.

Once enabled, Salesforce Timesheets and Shifts open with a High Assurance session for that tenant. If you turn it off, the tenant reverts to the previous behaviour.

Part 4 — Test and what to expect

Happy path

  1. On a device signed in to the tenant (current production Skedulo mobile app — no app update required), open a screen that embeds a Salesforce Visualforce page — for example, a Timesheet or Shift.
  2. Expected: the Visualforce page loads directly with no MFA prompt and no visible SSO or login step.

Confirm the session is High Assurance

In the customer’s Salesforce org:

  • Setup → Login History: the delegated login for that user appears as SAML Idp Initiated SSO (distinct from any incumbent identity provider’s SAML Sfdc Initiated SSO). This confirms Skedulo’s identity provider consumed the assertion.
  • The resulting session’s Session Security Level = High Assurance (visible via Setup → Session Management) — this is what satisfies MFA enforcement.

Rollback

To revert a tenant, turn Salesforce MFA delegation back off in Settings → System administration. The change takes effect immediately, and the tenant returns to its previous behaviour.

Troubleshooting

Symptom Likely cause Fix
Generic Salesforce login error in the WebView (“We can’t log you in…”) Org SSO not configured, wrong Issuer, or wrong/missing certificate Re-check Part 1: Issuer is exactly https://auth.skedulo.com/saml, Entity ID is https://saml.salesforce.com, and the production certificate from Part 2 is uploaded.
Visualforce page still prompts for MFA / loads a Standard session Salesforce MFA delegation is not enabled, so the tenant is still using the previous behaviour Confirm Salesforce MFA delegation is turned on for the tenant (Part 3).
Salesforce MFA delegation not visible in Settings Tenant is not Salesforce-backed, or your role lacks the Administrator role / Manage Salesforce MFA delegation permission Confirm the tenant’s platform vendor is Salesforce and that your user has the Administrator role or the permission.
Login fails after reloading or navigating back to the page The secure sign-in token can only be used once, and reloading reuses a spent token Expected — return to the screen from the app to load a fresh session.
Incumbent identity-provider staff logins disturbed Skedulo setting was enabled as a login option or added an org-global session policy Re-check Step 1.4: Skedulo must be IdP-initiated only, not an Authentication Service, with no Session Security Level Policies mapping.