Customer would like to remain on the SaaS connector but has a lot of account types that can’t be filtered out on aggregation. If we go the VA based connector we should be able to use a connector rule to strip out certain accounts.
If we remain on the SaaS connector does anybody know if we can use a buildmap rule with it, or how to best handle this with the SaaS connector?
From what I’m seeing on the API, there isn’t much of an option to filter accounts with the get users.
thanks,
Fred
Hi @ts_fpatterson
For the SaaS-based Jira connector, connector rules such as BuildMap are not supported because the processing happens in the SailPoint cloud rather than in a Virtual Appliance. BuildMap and other connector rules are generally only available for VA-based connectors.
If the customer wants to remain on the SaaS connector, a few alternative approaches could help:
Handle filtering through correlation logic
Configure correlation using a unique attribute such as email or employee ID so that only valid user accounts link to identities. Other accounts will remain uncorrelated.
Use account attributes to ignore certain account types
If the API returns attributes indicating account type (for example service accounts or bots), you can use those attributes in access modeling or governance policies to exclude them from identity access processes.
Post-processing in ISC
Allow all accounts to aggregate, but filter their usage by restricting them from certification, access requests, or role modeling.
API proxy or middleware (optional)
Some implementations place a lightweight API layer in front of Jira that filters users before ISC aggregates them.
If source-level filtering is critical, moving to the VA-based connector would provide more flexibility because connector rules like BuildMap can be used to filter accounts before they are ingested.
Actually, you cannot use any Connector Rules with the SaaS Web Services connector. Those rules require the Virtual Appliance to execute the BeanShell code.
To handle it with the SaaS connector you can check from the given options:
In case you use VA then you can use the rule -After operation Rule. write a few lines of code to intercept the response from the API and remove the unwanted objects from the list before they are sent to the SailPoint.
As much of SailPoint is moving heavily towards a SaaS emphasis, do we know if they are going to expand the framework / architecture to allow rules on the SaaS side for connectors? I feel an emphasis from some architects to push SaaS as much as possible.
I agree on the aggregation of everything approach for the most part, except in this case we have an accountType that is over 150k accounts that aren’t desired and the aggregations are close to an hour. While we may not be able to cut aggregation time by much, the bloated account base, is excessive, especially when you have to use APIs to assess the account data as the export doesn’t allow over 100k.
That’s interesting, is it documented somewhere? Thanks in advance 
Hi @ts_fpatterson ,
Can you please give it a try for below
Not exactly but you can get the more information on Sailpoint developer/Community sites.
Thanks
this isn’t working 
I believe I did everything correctly.
“filterString”: “(accountType != "customer")”,
Same result
I wonder if this parameter works across all SaaS connectors
