# Enable/Disable and Add/revolke Entitlement not picking up customizerinjected attributes on Web Services SaaS **URL:** \ **Category:** SHF Discussion and Questions\ **Tags:** webservice-connector, sailpoint-identity-security, connectors\ **Created:** [August 17, 2026, 1:52pm UTC](https://developer.sailpoint.com/discuss/t/enable-disable-and-add-revolke-entitlement-not-picking-up-customizerinjected-attributes-on-web-services-saas/219128 "2026-08-17T13:52:59Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![MRania](https://avatars.discourse-cdn.com/v4/letter/m/278dde/32.png) [@MRania](https://developer.sailpoint.com/discuss/u/MRania)\ **Post date:** [August 17, 2026, 1:52pm UTC](https://developer.sailpoint.com/discuss/t/enable-disable-and-add-revolke-entitlement-not-picking-up-customizerinjected-attributes-on-web-services-saas/219128/1 "2026-08-17T13:52:59Z")
Hello, I’m running into something on a Web Services SaaS source (target requires a full-object PUT, no PATCH) and wanted to check if I’m missing an easier way to do this. Used a customizer’s **beforeStdAccountUpdate** hook to fetch the current account and backfill any attribute that isn’t part of the actual change, so the operation body’s **$plan.x$** placeholders resolve instead of coming through blank. Tried it for Enable, Disable, and Add/revoke Entitlement and it doesn’t work, even when I confirmed via logging that the customizer was returning the right values (backfilled **changes** array had everything, correctly populated), the target still rejected the request with required fields blank. Dug into the SDK types and **StdAccountEnableInput** / **StdAccountDisableInput** genuinely don’t have an attributes field at all, so there’s nowhere for that data to go on those two. Add Entitlement does route through **beforeStdAccountUpdate** and still doesn’t work, which I can’t fully explain. Also tried the newer endpoint-level **isBeforeCustomizer / customizedOperation(‘X:before’, …)** approach, hoping to just rewrite \_requestConfig.body directly, but at that point **input** doesn’t have the account identity at all, so I couldn’t use it for per account data. What ended up working: have the hook do the actual write itself (GET the account, merge in the one real change, PUT directly), and change the native Enable/Disable/Add Entitlement HTTP operations from PUT to GET so they just refresh the account instead of trying to write with placeholders that don’t resolve. It works, but it feels like a workaround rather than the intended way to do this. Has anyone hit this same limitation, or is there a cleaner supported approach I’m missing? ---
**Author:** ![JackSparrow](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/jacksparrow/32/19685_2.png) [@JackSparrow](https://developer.sailpoint.com/discuss/u/JackSparrow)\ **Post date:** [August 18, 2026, 5:26am UTC](https://developer.sailpoint.com/discuss/t/enable-disable-and-add-revolke-entitlement-not-picking-up-customizerinjected-attributes-on-web-services-saas/219128/2 "2026-08-18T05:26:25Z")
Hello @MRania , I would recommend trying web services VA based connector, where we have the flexibility to modify the payload using web services before operation rule. You can have two HTTP Operation configured 1. GET 2. PUT ![image](https://global.discourse-cdn.com/sailpoint/original/3X/a/e/ae639f9279932de75fde77af345696e9896ef723.png) GET Operation gets you the existing data which you can capture in PUT operation using response placeholder ![image](https://global.discourse-cdn.com/sailpoint/original/3X/3/5/3557be8df7c0a0fa445853dfcc1a066ef83b497b.png) Now attach the before operation rule to PUT operation where you can modify the payload ---
**Author:** ![mcheek](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/mcheek/32/23705_2.png) [@mcheek](https://developer.sailpoint.com/discuss/u/mcheek)\ **Post date:** [August 18, 2026, 2:06pm UTC](https://developer.sailpoint.com/discuss/t/enable-disable-and-add-revolke-entitlement-not-picking-up-customizerinjected-attributes-on-web-services-saas/219128/3 "2026-08-18T14:06:46Z")
Not everyone has a VA to utilize, but luckily the Web Services SaaS connector has a rough equivalent of the before/after operation rule. It still uses a customizer, but specifically the .customizedOperation hook instead of the .beforeStd/.afterStd hooks that just manage the attribute requests. > **[Endpoint Customization](https://documentation.sailpoint.com/connectors/saas/web_services/help/saas_connectivity/web_services/endpoint_customization.html)** > > SailPoint Connectors Documentation ---
**Author:** ![mcheek](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/mcheek/32/23705_2.png) [@mcheek](https://developer.sailpoint.com/discuss/u/mcheek)\ **Post date:** [August 18, 2026, 2:27pm UTC](https://developer.sailpoint.com/discuss/t/enable-disable-and-add-revolke-entitlement-not-picking-up-customizerinjected-attributes-on-web-services-saas/219128/4 "2026-08-18T14:27:32Z")
Just so I understand, you tried BOTH a .beforeStd operation AND a .customizedOperation step and the data that should have been injected into the attribute requests by the former didn’t show up in the resulting requestEndpoint map on the latter? Maybe there’s some weird mismatch in your http operation variables? To answer your question though, I’ve definitely done direct to system calls from .before hooks then just removed those attribute requests from the plan (they were often a subset of the overall provisioning plen) ---
**Author:** ![system](https://global.discourse-cdn.com/sailpoint/original/2X/f/f2136700ed5e3703e0b85e02f6be799dacca7735.png) [@system](https://developer.sailpoint.com/discuss/u/system)\ **Post date:** [October 17, 2026, 2:28pm UTC](https://developer.sailpoint.com/discuss/t/enable-disable-and-add-revolke-entitlement-not-picking-up-customizerinjected-attributes-on-web-services-saas/219128/5 "2026-10-17T14:28:07Z")
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.