Role Removal - Disappearance from Access Request

[acrumley (Alex Crumley)]

Which IIQ version are you inquiring about?

8.5sp1

Please share any images or screenshots, if relevant.

Share all details about your problem, including any error messages you may have received.

Here is my application and role setup.

1. Application A - Delimited File type (creates manual work items on role request)
2. Business Role - Provisioning policy for Application A. (no entitlements)

When I request the role and it is added, it creates a manual work item. When I attempt to do a remove role request, the access request is blank and does not remove the role off of the cube. The only way to remove this role off of the cube is by batch request.

You may be thinking. Why do you have no provisioning? Well, we are tracking access of a disconnected application. We want people to track access via IGS roles. We are using policies to detect identity changes and automate workflows for removals. However, I don’t understand why I can’t remove the role off the cube. For the role owners, this makes management impossible. You can add but not delete!!!

Please help. I am very confused as to why only batch request is the only way for the role to be removed.

[msingh900 (Manish Singh)]

Can you share me the steps of how you are removing role from UI ?

[acrumley (Alex Crumley)]

Sure can! I will explain both the add and removal process:

Add Role Process
Log in as admin account

1. Click “Manage User Access” QuickLink
2. Search user “Alex Crumley”
3. Add Role, select “Base User”
4. Submit Access Request
5. Finish Manual Work item
6. View “Alex Crumley” Identity cube to see the role

Remove Role Process

1. Click “Manage User Access” QuickLink
2. Search user “Alex Crumley”
3. Remove Role, select “Base User”
4. Submit Access Request
   1. originally, I see “Remove Role - Base User”
   2. Then, after Perform Maintenance and Identity Request Maintenance, the item has disappeared from the access request and changes status to “Complete”
5. View “Alex Crumley” identity cube
6. Role is still assigned in Cube
7. Go to “Manage User Access”
8. Try to perfrom Add Role Process
9. Error says “Role is already assigned”

[acrumley (Alex Crumley)]

Here is the access request state upon submission and after the maintenance tasks are ran:

BEFORE:

AFTER: (perform maintenance and identity request maintenance is ran)

Saw this in syslog:

Funny enough, I did a new role in my QA environment, and it successfully removed an empty/no-entitlement role. It didn’t disappear. Saw the same syslog entries except this afterwards, seemed to move to a lower level:

[naveenkumar3 (Naveen Kumar)]

can you go to global setting and administration console and see any transaction for removal there , filter with identity or app name.

In the similar way can you check in Audit logs as well??

[SivaprakashRNTBCI (Sivaprakash P)]

Hi @acrumley
Please share the role provisioning policy.

[mandarsane]

Hi @acrumley ,

From provided information, it seems that when request to Add role was raised, it failed.

When 2nd request was raised, IIQ detected that Role is not provisioned to user, so there is nothing to remove, hence item is filtered out in access request.

Could you please check why Provisioning failed for initial request or provide more information so it can be identified. Make sure Provisioning is done properly (Aggregate account if direct provisioning is not supported).

[acrumley (Alex Crumley)]

The add role and “create account” action are present in the log. However, the removal did not make it to the provisioning transaction log.

[acrumley (Alex Crumley)]

That’s the thing. We are using this for access audit tracking only. The roles do not provision anything to the target accounts because it is a delimited file type with no file attached, hence the manual work items it produces.

I’ve done a similar thing on our QA environment, and it removes the role from the cube just fine. the access request for removal simply removes the role from the cube. There are no attributes unset or account deletion within that removal access request either (which is fine), and it still works to remove the role.

When I do the add access, it still provisions the role to the identity cube. Provisioning failures don’t matter to me actually because those attributes are simply to populate the work item to communicate to the sysadmin what has to be done.

[acrumley (Alex Crumley)]

Just a simple form with one attribute to define what the access level should be. Just piece of text saying how to provision the account:

[acrumley (Alex Crumley)]

One thing I also observed versus our DEV/QA and PROD environment was that DEV/QA cubes do not have role metadata, and PROD has role metadata. I am seeing the “RoleMetadator” failing due to a custom rule we have:

“March 10, 2026, 7:11 AM”,70548689,ERROR,The RoleMetadator failed to determine the entitlements that would be provisioned for identity 00318308,sailpoint.tools.GeneralException: Exception evaluating rule: CUSTOM_RULE,

this custom rule is in the provisioning policy for our Active Directory application, so honestly confused on how it is being triggered here. Something in the Identity Refresh step maybe?

[neel193 (Neelmadhav Panda)]

@acrumley Could you please open the access reuqest and see if it is marked as filtered? Please check and also share the access request xml for review.

[acrumley (Alex Crumley)]

XML

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE IdentityRequest PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<IdentityRequest completionStatus="Success" created="1773144243659" endDate="1773144303297" executionStatus="Completed" id="0ad200e29cc417a9819cd7a1fdcb3363" modified="1773144303297" name="0000337286" priority="Normal" requesterDisplayName="acrumley_adm" requesterId="0ad200e294f71c668194fb7027370f59" significantModified="1773144303297" source="LCM" state="End" targetClass="Identity" targetDisplayName="Alex Crumley" targetId="0ad200e48df81cd6818e3dc9f6bd0223" type="AccessRequest" verified="1773144303297">
  <Attributes>
    <Map>
      <entry key="provisionedProject">
        <value>
          <ProvisioningProject identity="00327512">
            <Attributes>
              <Map>
                <entry key="disableRetryRequest">
                  <value>
                    <Boolean>true</Boolean>
                  </value>
                </entry>
                <entry key="identityRequestId" value="0000337286"/>
                <entry key="optimisticProvisioning" value="false"/>
                <entry key="requester" value="acrumley_adm"/>
                <entry key="source" value="LCM"/>
              </Map>
            </Attributes>
            <MasterPlan>
              <ProvisioningPlan>
                <AccountRequest application="IIQ" op="Modify">
                  <Attributes>
                    <Map>
                      <entry key="attachmentConfigList"/>
                      <entry key="attachments"/>
                      <entry key="flow" value="AccessRequest"/>
                      <entry key="id" value="0ad200e19cc417b7819cd29acb0e211f"/>
                      <entry key="interface" value="LCM"/>
                      <entry key="operation" value="RoleRemove"/>
                    </Map>
                  </Attributes>
                  <AttributeRequest assignmentId="33cb7f4cefdc4508829630a33f19ab88" name="assignedRoles" op="Remove" value="Base User">
                    <Attributes>
                      <Map>
                        <entry key="comments" value="Test removal - again"/>
                        <entry key="deassignEntitlements">
                          <value>
                            <Boolean>true</Boolean>
                          </value>
                        </entry>
                      </Map>
                    </Attributes>
                  </AttributeRequest>
                </AccountRequest>
                <Attributes>
                  <Map>
                    <entry key="identityRequestId" value="0000337286"/>
                    <entry key="requester" value="acrumley_adm"/>
                    <entry key="source" value="LCM"/>
                  </Map>
                </Attributes>
              </ProvisioningPlan>
            </MasterPlan>
            <ProvisioningPlan targetIntegration="IIQ" trackingId="3cba7aaf4cbf4788b30653217ed6c7d6">
              <AccountRequest application="IIQ" op="Modify">
                <Attributes>
                  <Map>
                    <entry key="attachmentConfigList"/>
                    <entry key="attachments"/>
                    <entry key="flow" value="AccessRequest"/>
                    <entry key="id" value="0ad200e19cc417b7819cd29acb0e211f"/>
                    <entry key="interface" value="LCM"/>
                    <entry key="operation" value="RoleRemove"/>
                  </Map>
                </Attributes>
                <AttributeRequest assignmentId="33cb7f4cefdc4508829630a33f19ab88" name="assignedRoles" op="Remove" value="Base User">
                  <Attributes>
                    <Map>
                      <entry key="comments" value="Test removal - again"/>
                      <entry key="deassignEntitlements">
                        <value>
                          <Boolean>true</Boolean>
                        </value>
                      </entry>
                    </Map>
                  </Attributes>
                </AttributeRequest>
              </AccountRequest>
              <Attributes>
                <Map>
                  <entry key="identityRequestId" value="0000337286"/>
                  <entry key="requester" value="acrumley_adm"/>
                  <entry key="source" value="LCM"/>
                </Map>
              </Attributes>
            </ProvisioningPlan>
            <ProvisioningTarget assignmentId="33cb7f4cefdc4508829630a33f19ab88" role="Base User">
              <AccountSelection applicationId="0ad200e19cc417b7819cd28e41f320f1" applicationName="DACS - Standalone" doCreate="true"/>
            </ProvisioningTarget>
			
			.... other provisioning targets
            <ProvisioningTarget assignmentId="74ba204d7f504e218ecc723c8c2907da" retain="true" role="Y12_team_Requestable_Role">
              <AccountSelection applicationId="0ad200e18a191ba5818a19fbeb780018" applicationName="Active Directory" selection="ACCOUNT NATIVE IDENTITY">
                <AccountInfo displayName="ONENET\ACRUMLEY" nativeIdentity="ACCOUNT NATIVE IDENTITY"/>
              </AccountSelection>
            </ProvisioningTarget>
          </ProvisioningProject>
        </value>
      </entry>
      <entry key="taskResultId" value="0ad200e29cc417a9819cd7a1fa8f3360"/>
    </Map>
  </Attributes>
</IdentityRequest>

Looks like no target was made?

Since I am seeing in the logs that the access request contains error logs related to AD account targeting, is it possible that it can’t decide the remove the role because of the errors?

[acrumley (Alex Crumley)]

Looked at another access request in another environment with a dummy role (no entitlements for a delimited file application)

The account request had targetIntegration=“IIQ” on both provisioning plan and Account request levels. However, what I just pasted does not.

<ProvisioningPlan targetIntegration="IIQ" trackingId="34bf7bf0c8c4496c9ccd4841860f90f9">
<AccountRequest application="IIQ" op="Modify" targetIntegration="IIQ">

Another big thing is there are no RequestItems and IdentityRequestItems at the bottom.

[neel193 (Neelmadhav Panda)]

If there are no entitlements, then only role will be assigned. I have few more questions, let me ping you over chat.

[acrumley (Alex Crumley)]

Figured it out. I originally created these roles by cloning existing ones that had a very similar structure and provisioning policies. However, this method caused the role to be bugged. My theory is something in the XML did not get fully duplicated and caused the provisioning engine to be confused when trying to remove the role.

By copying the XML, stripping it of id’s and such, and re-importing it, access requests related to those roles are fine.