SCIM "active" attribute logic

I’m building out a SCIM 2.0 SaaS source, and am hitting a bit of a road block. In the destination system, the “active” SCIM attribute has the opposite logic that you’d expect.

When an account is enabled: active = false

When an account is disabled: active = true

The Sailpoint SCIM connector logically does it the normal way. How can I make it do the opposite? I tried adding Enable & Disable provisioning policies via VSCode but that didn’t work. Ex.

{
    "name": "Disable",
    "description": null,
    "usageType": "DISABLE",
    "fields": [
        {
            "name": "active",
            "transform": {
                "type": "static",
                "attributes": {
                    "value": true
                }
            },
            "attributes": {},
            "isRequired": false,
            "type": "boolean",
            "isMultiValued": false
        }
    ]
}

With this in place, it still sets “active” to false during disables.

Hi Chris,
Its seems from description that you are facing problem in aggregation to represent correct account status Method 1: Customization Rule : - This rule hooks into the aggregation process.
Method 2: Ask system API to add a new custom field : - You can map new custom field from SCIM api response with the active field.

Just to clarify, Method 1: A Before Provisioning rule?

I don’t think this can be overridden in the SailPoint SCIM 2.0 SaaS connector.
Enable/Disable for SCIM is handled with the connector’s built-in active logic, so your provisioning policy won’t flip it.

Since your target uses reversed semantics, it’s basically non-standard SCIM behavior.

Best fix is to handle the inversion on the target side or through middleware.
If you need full control of the payload, I’d switch to Web Services or a Custom SaaS connector.

I opened an Ask an Architect case just for good measure, and their recommendation for this was to use a SaaS Customizer Getting Started | SailPoint Developer Community

After reviewing those and seeing everything required, I decided to bail on SCIM for this system and use their REST API via Web Services connector instead.

It was BuildMap Rule anyway you have good new option to implement