When requesting multiple roles through the Manage Access, it processes only one role at a time

[ManikantaMattaparthi]

Which IIQ version are you inquiring about?

8.5p1

Please share any images or screenshots, if relevant.

When using the Manage Access to request multiple roles, the system currently processes only one role at a time. Even if multiple roles are included in the request, the API assigns only a single role instead of creating all requested roles. I also tried hardcoding a second role in the “before provisioning” rule by adding an attribute request, but that approach did not work—the system still accepts only one role.

For example, if I request roles A, B, and C through Manage User Access, only the last role (C) is sent to the API, while roles A and B are ignored. Could anyone please help me resolve this issue?

Connector: Webservice application
Restriction: We must use form-data only, because the API does not support JSON format.

Please share any other relevant files that may be required (for example, logs).

[Please insert files here, otherwise delete this section]

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

[Replace this text with the problem that you are facing]

[ManikantaMattaparthi]

This is how test client accepting multiple roles :

[ManikantaMattaparthi]

Configuration from application side :

[Chathuryas (Chathurya Simhadri)]

Hi @ManikantaMattaparthi ,

Could you please confirm if the role attribute is multi-valued and the API supports multiple values for the role attribute.

you can use a before operation rule to print the plan and check if all the requested roles are getting populated in role attribute in body for the API

[Chathuryas (Chathurya Simhadri)]

@ManikantaMattaparthi You can check if the role attribute support multiple values like comma separated values or not by testing the API in the postman by giving the comma separated values in the body of the API

[ManikantaMattaparthi]

I tried both approaches, but the API does not support comma‑separated values. Regardless of how the request is structured, it only accepts a single role at a time.

[Chathuryas (Chathurya Simhadri)]

@ManikantaMattaparthi After the request is submitted. does the API is replacing the role attribute with only new requested role for the user or is it appending to already existing roles.

Ex: If the user has Role A before requesting role B and the user now has only role B.

If the API does not support multiple values for role, then only last value is considered.

Can you also try sending the roles as an array in Postman

[punna0001 (harish Punna)]

Hey Manikanta,

Manage Access isn’t the issue here. The first thing I would actually confirm is whether the provisioning plan contains all three roles @Chathuryas already pointed at this above and worth doing before anything else.

From the symptom though, this looks like classic payload-construction collapse. Your target API only accepts one role per call, so when the connector resolves multiple role values into the same form-data field, the last one wins. That’s why C lands and A and B vanish.

Comma-separated and array won’t save you since you already confirmed the API rejects both.

Before touching rules, sanity-check the connector config:

1. Is role marked as Entitlement + Multi-Valued in the schema?

2. Do you have an actual Add Entitlement operation for that attribute, or are role adds going through Update Account?

3. Is addRemoveEntInSingleReq left alone (default false)?

If those three are right, the connector should be firing the Add Entitlement endpoint once per role on its own. The docs spell this out: with addRemoveEntInSingleReq=false, each value goes in its own request. So you’d get:

POST role=A
POST role=B
POST role=C

If it’s set to true, the connector tries to bundle them into one array payload, which your API can’t take anyway. So leave it false.

If config checks out and you’re still seeing only C land, drop into a WebServiceBeforeOperationRule and log the plan as the very first thing:

log.error("PLAN: " + provisioningPlan.toXml());

If A, B, C are all in the plan but only C makes it out, you’ve confirmed the loss is in payload construction. From there, loop the role AttributeRequests in the rule and fire restClient once per value yourself. That gives your API what it actually supports, one request per role.

[ManikantaMattaparthi]

No, it’s not like that. When I request multiple roles in a single request, the API ends up appending only the last role. For example, if user Manikanta already has role A and then requests roles B and C together, SailPoint shows both roles in the access request. However, the API only processes role C, so the user ends up with roles A and C, while role B is ignored. I also tried sending the roles as an array, but that approach did not work either.

[ryan_toornburg]

I am assuming this is a custom application. Do you have the API documentation for the method you are calling? If it is consistent with only pr0cessing the last role, maybe an After Rule could split and do additional requests for the preceding roles.

[naveenkumar3 (Naveen Kumar)]

@ManikantaMattaparthi

When I request multiple roles in a single request, the API ends up appending only the last role. For example, if user Manikanta already has role A and then requests roles B and C together, SailPoint shows both roles in the access request. However, the API only processes role C, so the user ends up with roles A and C, while role B is ignored. I also tried sending the roles as an array, but that approach did not work either.

The issue occurs because:

1. SailPoint’s default behavior for multi-role requests in Manage Access sends one role per API call sequentially
2. Form-data limitation - APIs expecting roleId as a single field overwrite previous values instead of accumulating
3. Webservice connector processes requests individually, not all the roles

Step 1: Create Custom Before Provisioning Rule
like below

 
  
  <Java>
    import sailpoint.api.SailPointContext;
    import sailpoint.object.ProvisionPlan;
    import sailpoint.object.ProvisionPlan.AccountRequest;
    import sailpoint.object.ProvisionPlan.AttributeRequest;
    import sailpoint.tools.GeneralException;
    import java.util.List;
    import java.util.ArrayList;
    import java.util.Map;
    import java.util.HashMap;
    
    // Get all Add role requests for current request
    List&lt;AccountRequest&gt; addRequests = new ArrayList&lt;&gt;();
    List&lt;String&gt; allRoles = new ArrayList&lt;&gt;();
    
    for(AccountRequest accReq : plan.getAccountRequests()) {
        if("Add".equals(accReq.getOperation()) &amp;&amp; "role".equals(accReq.getNativeIdentity())) {
            addRequests.add(accReq);
            // Extract all role IDs from attribute requests
            for(AttributeRequest attrReq : accReq.getAttributeRequests()) {
                if("roleId".equals(attrReq.getName()) &amp;&amp; attrReq.getValue() != null) {
                    allRoles.add(attrReq.getValue().toString());
                }
            }
        }
    }
    
    if(allRoles.size() > 0) {
        // Clear existing single role requests
        plan.getAccountRequests().removeIf(req -&gt; 
            "Add".equals(req.getOperation()) &amp;&amp; "role".equals(req.getNativeIdentity())
        );
        
        // Create SINGLE  request with all the acces submitted
        AccountRequest batchRequest = new AccountRequest();
        batchRequest.setNativeIdentity("role");
        batchRequest.setOperation(sailpoint.object.ProvisionPlan.Operation.Add);
        batchRequest.setApplication(plan.getApplication());
        
        // Create roles array for form-data
        String rolesArray = String.join(",", allRoles);
        
        AttributeRequest rolesAttr = new AttributeRequest();
        rolesAttr.setName("roles");  
        rolesAttr.setValue(rolesArray);
        rolesAttr.setUnstructured(true);
        
        batchRequest.getAttributeRequests().add(rolesAttr);
        plan.getAccountRequests().add(batchRequest);
        
        log.info("MultiRoleprocessed " + allRoles.size() + " roles: " + rolesArray);
    }
  
</Rule>

Make sure your field should be something like below

Form Fields:
Name: “roles”
Type: String (Multi-value)
Method: POST

Check at the application end, Your API must accept comma-separated roles or array format :

Form fields:

• userId: “manikanta”
• roles: “roleB,roleC” // Comma-separated
  or like below
• roles: “roleB”
• roles: “roleC” // Array format

[neel193 (Neelmadhav Panda)]

@ManikantaMattaparthi

• Set multi=true in your schema for Roles attribute.
• Could you please print the plan in Before Provisioning Rule and Before Operation rule and share it here?

[suresh_musireddy]

@ManikantaMattaparthi Review provisioning transactions. I think SailPoint calling API three times and updating the roles with last value.

For Quick Test :

In Body → provide multiple roles manually (Static values) and test the request access. Now if your account have all the roles mentioned in the body then you need to follow below approach

You need to have BeforeOperationRule in Webservice connector

Get the all the existing roles information from link

Customize the body in rule by including all existing roles and requested roles. If remove request is there then you need remove from final list

Then you will see all roles in target application.

Some applications always expect all the roles in payload instead delta.

[ManikantaMattaparthi]

I tried passing the roles both as a comma‑separated string and as an array format. The API is not accepting the input in either way.

[ManikantaMattaparthi]

Yes madhav, in schema the attribute we set multi=true.

[ManikantaMattaparthi]

@suresh_musireddy

In Body → provide multiple roles manually (Static values) and test the request access. Now if your account have all the roles mentioned in the body then you need to follow below approach

Hi Suresh, In SailPoint it’s not accepting multiple keys with the same key name. For example, if my key name is roles and I try to add two roles keys in the body, it only saves one because SailPoint does not allow duplicate keys.

[Peddapolu (Venkateswar Rao Peddapolu)]

Hi @ManikantaMattaparthi ,

I don’t think so, the SailPoint schema attribute doesn’t allow duplicate keys. However, in your case, there is no need to add any extra keys. Since roles are entitlements and multi valued, SailPoint will call the API for each and every entitlement, just send the role value into the JSON body. As you shared in the screenshot above, you added roles twice in the postman, add them only once and send the single attribute and single value into it, it will work. If you are still facing issues, please send the input JSON body.

Thanks,

PVR.

[naveenkumar3 (Naveen Kumar)]

did you try with the before provisioning rule, which i suggested above??

[suresh_musireddy]

Please share curl command from postman. It will help us to understand the request format and body details.

[ManikantaMattaparthi]

Yes same thing i tried.