Best Approach for Integrating Salesforce UI with SailPoint IIQ for Identity & Access Requests

IdentityIQ (IIQ) IIQ Discussion and Questions
, , , ,
1

Which IIQ version are you inquiring about?

8.3p4

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

Hi everyone,

I’m exploring an integration pattern where Salesforce will act as the front-end UI for managing access requests for a specific type of Identity in SailPoint IIQ. The business wants Salesforce users to:

  1. Search for identities

  2. Search and display only applicable roles/access items (filtered based on identity type)

  3. Submit access requests from within Salesforce

Once the request is submitted in Salesforce, it needs to be sent to SailPoint so IIQ can:

  • Receive the request

  • Trigger the appropriate workflows

  • Perform provisioning as usual

I’m trying to determine the best-practice approach for exposing IIQ data and services to Salesforce. Some questions I’m considering:

  • What’s the recommended way for Salesforce to retrieve identity and role data from IIQ?
    Would exposing selected SailPoint REST APIs be the right approach, and how should I securely limit role visibility?

  • What is the cleanest method for IIQ to receive submitted request data from Salesforce?
    Should Salesforce call an IIQ REST API endpoint, do we use workflow triggers, or is there a preferred integration pattern for this type of request orchestration?

  • Any guidance or lessons learned from anyone who has implemented Salesforce → SailPoint IIQ access request integrations would be greatly appreciated.

Open to best practices, architectural suggestions, or alternative approaches. Thanks in advance!

2

@karangulati IIQ already has integration with ServiceNow for similar use case. However for salesforce, it is not there. It’s an interesting use case :slight_smile: .

To achieve this, you need to leverage IIQ REST API module, either OOTB or you can build your set of APIs which you will need in Salesforce to load the user details, account details, entitlement details, to generate access request in IIQ, to manage the approvals and finally to provision the access to applications. And you may need additional endpoints like query historical request, query the request status, etc. But with strong API architecture you can achieve this.

Note: Found a fix? Help the community by marking the comment as solution. Feel free to react(:heart:, :+1:, etc.) with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.

1 Like
3

Hi @neel193, Thanks for the response appreciate it.

Yes, I’m familiar with the ServiceNow integration/use case, but in this scenario the business requirement is to use Salesforce as the front-end UI, so we’re looking to implement a similar pattern there.

I’ve started reviewing the IIQ REST API module and I can see how some of the OOTB endpoints could be leveraged. When you mentioned “you can build your set of APIs which you will need in Salesforce,” could you please clarify what you mean by that?

  • Do you mean creating custom REST endpoints within IIQ (e.g., via a plugin / REST extension) that wrap IIQ services/workflows?

  • Or exposing additional APIs that apply business filtering (e.g., return only applicable roles/access items based on identity type), enforce security controls, and simplify the Salesforce integration?

  • If you’ve done something similar, what’s the recommended/cleanest approach in IIQ 8.3 to implement these custom endpoints, and any key considerations?

Any pointers, examples, or best-practice guidance on how to implement this “custom API layer” in IIQ would be really helpful.

Thanks again,
Karan

4

@karangulati Yes. I meant create a specific REST APIs using Plugins for your usecase. Before that you can try to see if OOTB REST/SCIM APis can fulfil your use case or not.

As you want to have a UI in Salesforce, you want to figure out first what all fields would be there in the UI and what all services you want to offer there, then accordingly start noting down the dependencies on IIQ. Then you can start looking for existing APIs which can fulfil your usecase, else create custom ones. This implementation requires a careful design and architecture to make sure no access is provision outside the expected flow, otherwise it may lead to compliance issues.

Note: Found a fix? Help the community by marking the comment as solution. Feel free to react(:heart:, :+1:, etc.) with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.

1 Like