Yeah, it’s a lot of output, but I’ve seen worse, lol. Something I did notice is that the initial plan (on line 630), you can see the userPassword AttributeRequest and is has a value. Skip forward a bit to where you enter the Starting workflow SP Provision Processor Sub (line 736), something has modified the plan (as you can see on the plan in the variable starting on line 814, the password is gone: <AttributeRequest name="userPassword" op="Set"/> (line 824). That “mysteriously updated” plan carries through to the Starting step Compile Project stage (line 992, with the output Project XML on line 994). Notice in both the project MasterPlan and the compiled Plan both contain the same <AttributeRequest name="userPassword" op="Set"/>.
It looks like that somehow got pulled into the ApprovalSet (line 1436-1447). The IdentityRequestItem also has no reference to a value component (lines 1506-1512). The ApprovalSet gets auto-approved (as seen on 2351-2384), and the password value reappears in the plan output variable (line 2476), but not in the project output variable (line 2389). It then moves to the provisioning phase where it recompiles the project (line 2978), but the userPassword value is still absent in both the MasterPlan and Plan sections of the project return from that step. Moving forward to the Starting workflow Provision with retries subprocess (line 3211), you can see that the input project is still there with no password value (3243). So it looks like that one is the one that is being executed by the provisioner (that subprocess ends at line 3482 with no indication of errors, as the return project variable indicates success via <ProvisioningResult status="committed"/> on line 3572). The Starting step Post Provision seems to indicate a project with a value for password was executed (line 3866-3960), but the project return from the SP Identity Request Provision on line has no password value.
Now I’m not big into the SSF myself, so I could be wrong, but it looks like an incomplete/incorrect project is being executed. It’s certainly possible that the password value is being deliberately stripped from the SSF workflow trace output, but I find that pretty unlikely - especially since it shows up in other parts of the logs as one would expect.
Just for a sanity-check, I’d suggest attempting to test a password change outside the Leaver process (and the SSF). Take one of the plan XMLs that you have in that log and tweak it to a suitable test case and attempt to execute it via the OOB LCM Provisioning workflow, or even via the console provision command (see IIQ Console for testing Provisioning Rule - IIQ 8.2 - #2 by brian_weigel).