Hi Everyone,
I am trying to input an account filter string, and it seem to not work. My condition is to ignore if logon doesnt contain sailpoint.net and if market is abc or market is cde
can someone help me because this filter throws an error
“account.filterString”: “!(login.endsWithIgnoreCase("sailpoint.net")) and !(market == "abc" or market == "cde")”
account.filterString”: “!(login.endsWithIgnoreCase(“sailpoint.net”)) and (market == “abc” or market == “cde”)
You should not have NOT for market code
Hi @Soundary
Could you please try “&&” , “||” instead “and” , “or”
account.filterString”: “!(login.endsWithIgnoreCase(“sailpoint.net”)) || (market == “abc”)
is this valid?
Try this
"account.filterString": "!(login.endsWithIgnoreCase(\"sailpoint.net\")) && (market == \"abc\" || market == \"cde\")"
Given your requirements, the equivalent inclusion logic would be:
login ends with sailpoint.net.market is not abc and not cde."account.filterString": "login.endsWithIgnoreCase('sailpoint.net') && market != 'abc' && market != 'cde'"
If you prefer to use negation to exclude accounts, you can structure the filter as follows:
"account.filterString": "!(login.endsWithIgnoreCase('sailpoint.net')) && !(market == 'abc' || market == 'cde')"
Thank you!
Hi Amit,
I did try both of the filters. it shows an error and doesn’t seem to filter the accounts
Hi Krishna,
This filter didn’t actually filter the condition. when the aggregation ran
Hi @Soundary -
I’m not entirely sure I know exactly what you’re trying to achieve. Do you ignore if the account doesnt contain sailpoint.net and the account is in one of the markets, or to ignore accounts not containing sailpoint.net and ignore accounts being in one of the markets?
Scenario 1:
account: [email protected], market: abc - ignore
account: [email protected], market: xyz - include
account: [email protected], market: abc - include
account: [email protected], market: xyz - include
Scenario 2:
account: [email protected], market: abc - ignore
account: [email protected], market: xyz - ignore
account: [email protected], market: abc - ignore
account: [email protected], market: xyz - include
You then need to turn your ignore statement into an include statement:
Scenario 1:
Return accounts that end sailpoint.net OR are not in market abc or cde
Scenario 2:
Return accounts that end sailpoint.net AND are not in market abc or cde
The filters would be:
Scenario 1:
(login.endsWithIgnoreCase(\"sailpoint.net\") || !(market == \"abc\" || market == \"cde\"))
Scenario 2:
(login.endsWithIgnoreCase(\"sailpoint.net\") && !(market == \"abc\" || market == \"cde\"))
Having said that, my recommendation would be to build the filter one condition at a time, such as (login.endsWithIgnoreCase(\"sailpoint.net\")
check it gives expected results and add to it until you get the desired result.
@Soundary For your case the query that @MVKR7T @officialamitguptaa sent should work.
“account.filterString”: “!(login.endsWithIgnoreCase(‘sailpoint.net’)) && !(market == ‘abc’ || market == ‘cde’)”
The above query works for me also make sure the value is coming for the mentioned attributes/
Thanks,
Shantha Kumar
Hi everybody,
I spoke to @Soundary regarding her resulting filter and despite the filter imports the right accounts, I noticed this is NOT consistent with the documentation and with filters we implemented for other sources (e.g.: Okta connector).
Following the docs, account.filterString should be used to STOP the import of matching accounts:
Accounts which match the filter string will be filtered. Accounts which do not match, will be sent to IdentityNow as normal.
Hence if the filter is set to "market != \"abc\"" only accounts whose market is abc will be imported.
When such filter was applied to a WebServices connector, the result was the opposite: all accounts with market different than abc were imported.
This leads to believe that account.filterString implementation for WebServices has a bug which is the reason it doesn’t bring the results that @Soundary was expecting to receive. @colin_mckibben, who do we report this issue?
A support ticket would be appropriate on this case. Thank you for the analysis and resolution.
We’ll do Colin, thank you!
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.