SAML SSO attribute mapping issues in HR core module blocking new employee onboarding

ERP NetSuite
, , , , , , , ,
1

We’re facing a critical blocker with our SAML SSO integration that’s preventing new employee onboarding. When new hires authenticate through our identity provider (Okta), they successfully log into NetSuite, but their user records are created without any assigned roles. The SAML assertion appears to be missing the role attribute that should map to NetSuite roles.

What’s strange is that manual role assignment through the NetSuite UI works perfectly - we can assign the appropriate HR roles and permissions without issues. But this defeats the purpose of automated provisioning and we’re now breaching our onboarding SLA as HR admins have to manually configure every new user.

Our SAML configuration has worked flawlessly for existing employees, but something about the initial provisioning flow for new users isn’t capturing or mapping the role attributes correctly. We’re on 2024.1 and this started affecting us after migrating to a new Okta tenant. Anyone dealt with SAML attribute mapping failures specifically during new user provisioning?

2

Check your SAML attribute statements in Okta. The role attribute needs to be explicitly defined in the application configuration. Go to your NetSuite app in Okta > Sign On > Edit SAML Settings and verify that you have an attribute statement mapping your Okta groups to a custom attribute like ‘netsuiteRole’. NetSuite won’t automatically pick up role information unless it’s explicitly mapped.

3

Good catch on the JIT provisioning - it is enabled and we do have a default role set. I examined a SAML response and I can see group membership attributes are being sent, but they’re in a different format than our old tenant used. The new tenant sends them as ‘groups’ instead of ‘memberOf’. I updated the attribute mapping in NetSuite but new users still aren’t getting roles assigned automatically.

4

You’ve hit a common but poorly documented issue with SAML SSO and JIT provisioning in NetSuite 2024.1, particularly when migrating identity providers. Let me walk you through the complete solution that addresses all three aspects of your problem.

Understanding Why SAML Assertion Missing Role Attribute:

The core issue is that NetSuite’s SAML implementation requires role information to be passed in a very specific format during JIT provisioning. When you migrated to the new Okta tenant, the attribute format changed from ‘memberOf’ to ‘groups’, but more critically, the values themselves are probably in a different structure. NetSuite expects role mappings to use either:

  1. NetSuite internal role IDs (numeric)
  2. Role names that exactly match your NetSuite role records
  3. A custom attribute you’ve explicitly mapped in SAML configuration

Your SAML assertion is likely sending group names like ‘HR-Employees’ or ‘Onboarding-Team’, but NetSuite doesn’t know how to translate these to actual NetSuite roles.

Why Manual Role Assignment Works:

Manual assignment works because you’re directly selecting NetSuite role objects through the UI, bypassing the SAML attribute mapping entirely. This proves your role configuration is correct - the issue is purely in the SAML-to-NetSuite translation layer.

Complete Solution for Automated Provisioning:

Step 1: Configure Okta Attribute Mapping

In your Okta NetSuite application:

  • Go to Applications > NetSuite > Sign On tab
  • Click Edit under SAML 2.0 Settings
  • Add a custom attribute statement:
    • Name: netsuiteRoles (this is what NetSuite will look for)
    • Name format: Unspecified
    • Value: Use Okta Expression Language to transform groups

Example expression:


String.replace(String.join(",", user.groups), "HR-Employees", "3")

Where “3” is your NetSuite HR Employee role internal ID.

Step 2: Configure NetSuite SAML Attribute Mapping

In NetSuite:

  • Navigate to Setup > Company > Setup Tasks > Single Sign-On
  • Click on your SAML SSO configuration
  • Under ‘Attribute Mappings’ section, add:
    • SAML Attribute: netsuiteRoles
    • NetSuite Field: Role
    • Mapping Type: Direct

Step 3: Set Up Role Mapping Table

Create a mapping document that correlates:

  • Okta Group Name → NetSuite Role Name → NetSuite Role Internal ID

For example:

  • HR-Employees → Employee: HR → 3
  • HR-Managers → HR Manager → 15
  • Onboarding-Coordinators → HR Onboarding → 22

You’ll need these internal IDs for your Okta expression.

Step 4: Handle Multi-Role Scenarios

If users can have multiple roles, configure Okta to send comma-separated role IDs:


String.join(",", Arrays.transform(user.groups, "groupToRoleID"))

And in NetSuite SAML settings, set ‘Multiple Roles’ to ‘Allowed’.

Resolving Onboarding SLA Breaches:

Immediate workaround while implementing the above:

  1. Create a ‘New Hire Default’ role with minimal permissions
  2. Set this as the ‘Default Role for JIT Users’ in SAML settings
  3. Implement a scheduled script that runs hourly to:
    • Identify users with only the default role
    • Check their Okta group membership via API
    • Assign appropriate roles programmatically

This gets new hires into the system immediately while proper role assignment happens within an hour.

Testing the Solution:

  1. Create a test user in Okta with known group memberships
  2. Have them authenticate to NetSuite via SAML
  3. Verify their user record shows correct role assignments
  4. Check Setup > Company > System Notes to see the JIT provisioning activity

Common Gotchas:

  • Role internal IDs can differ between NetSuite environments (sandbox vs production)
  • Some role types (like ‘Administrator’) can’t be assigned via JIT for security reasons
  • NetSuite caches SAML configurations for up to 15 minutes - wait after changes

After implementing this solution, your new employee onboarding should be fully automated again, and you’ll meet your SLA requirements without manual intervention.

5

I’ve seen this when migrating between Okta tenants. The new tenant probably has different group naming conventions or the attribute mapping format changed. Export a SAML response from Okta for a test user and examine the actual XML - look for what attribute names are being sent. Then compare those to what NetSuite is expecting in your SAML attribute mapping configuration.

6

The issue is probably with the attribute value format, not just the attribute name. NetSuite expects role identifiers in a specific format for SAML mapping. If Okta is sending group names like ‘HR-Employees’ but NetSuite is looking for internal role IDs or specific formatted strings, the mapping will fail silently. You need to create a custom attribute in Okta that transforms your group names into the exact format NetSuite expects.