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. Users get an MFA-compliant session with no app update and no extra login step.

Enabling a tenant has two independent gates, both required:

  • Regional master switch: managed by Skedulo and already ON across all regions. You do not need to do anything here.
  • Per-tenant setting: the Salesforce MFA delegation settings in the Skedulo web app: a Salesforce Login URL you paste in, plus a toggle that defaults to off. Both are self-service and are the last steps below. The toggle only works once the Login URL is saved; enabling delegation without it makes Visualforce pages fail to load.

Prerequisites (per tenant)

  • The tenant is in a supported 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 it 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. Skedulo cannot detect the upstream identity provider’s MFA directly, which is why this is an admin-set option rather than an automatic check. 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 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 User’s Salesforce username
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: Copy the Salesforce Login URL

After saving, Salesforce displays a Login URL for the new SSO setting (on the Single Sign-On Settings detail page). Copy this value exactly. You will paste it into the Skedulo web app in Part 3. Skedulo uses it, byte for byte, as the destination of the SAML assertion, so it must match the Skedulo SSO configuration precisely.

The remaining checks in this Part (Step 1.4 and Step 1.5) are verification only: you are confirming that Skedulo’s SSO setting does not disturb existing logins. Do not change anything on those pages.

Step 1.4: Do NOT enable it as a login option

This step is verification only; do not change any setting here. Confirm both of the following, so Skedulo’s identity provider stays scoped to the delegated Visualforce session only:

  • Go to Setup > My Domain and find the Authentication Configuration section. In the Authentication Service field, confirm that Skedulo SSO does not appear in the list at all. The list should show only the org’s normal login options, for example Login Form and the customer’s own identity provider (such as Azure AD SSO). An SSO setting only appears here once it has been ticked as an authentication service, so its absence confirms it is not selectable on the login page. If Skedulo SSO does appear, edit the section and untick it.
  • 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, so the incumbent identity provider’s logins stay 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 SAML public certificate

Upload this exact certificate as the Identity Provider Certificate in Step 1.2. It is the same certificate for every org (a single global signing identity). Copy the whole block, including the BEGIN/END lines, into a file named e.g. skedulo-saml.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. In the Salesforce Login URL field, paste the Login URL you copied in Step 1.3, exactly and with no edits, then click Save. This must be the Login URL from the Skedulo SSO configuration (not another provider’s, on multi-IdP orgs).
  5. Turn the Salesforce MFA delegation toggle on.
  6. 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 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), which 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 certificate from Part 2 is uploaded.
“Single Sign-On Error” on the Visualforce page; SAML Assertion Validator shows “Unable to map the subject to a Salesforce user” SAML Identity Type is set to Federation ID instead of Username, so Salesforce can’t match the asserted username In Step 1.2 set SAML Identity Type to “Assertion contains the User’s Salesforce username”.
Visualforce page fails to load right after enabling delegation; validator shows a recipient/“Incorrect SAML assertion recipient” mismatch The Salesforce Login URL in the Skedulo setting is missing, or does not match the Skedulo SSO configuration (e.g. another provider’s URL was pasted) Copy the Login URL from the Skedulo SSO setting (Step 1.3) and paste it, unedited, into the Salesforce Login URL field (Part 3).
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.