If I was hopeful I’d check if this was a transient issue as the https://scim.freshservice.com/scim/v2 endpoint, afterall, is hosted by Freshworks.

For what it’s worth, I get a 400 Bad Request if I attempt the strange GET request that Provisioning is attempting to perform in your example (I don’t understand what it’s trying to achieve with that filter and it might not apply to my environment anyway):

If I do a request to just https://scim.freshservice.com/scim/v2/Users I get a 200 OK.

Are you seeing this error en-masse or just on a few user import records?  Are some successful and others are not?

I’d try and look for something common in the user objects that it’s trying to import that are failing - hopefully there’s some sort of trend.  Like, are there any issues with the properties that are mandatory like their ‘userPrincipalName’, ‘givenName’ and ‘surname’?

Also, what happens if you Stop provisioning and then Start it again - does the issue persist?

I would e-mail the app dev’s so they can see the logs. 

I have managed to resolve this with the below response from the Dev team. I think I may have changed this by mistake .

--

The error happens because emailmtype eq work] cannot be used as a matching precedence. Unfortunately, we cannot remove this configuration from the Azure UI as it is the standard with the all Azure SCIM apps.

The selection of “​emailntype eq work]” as the matching precedence has caused the “BadRequest” error message. Considering that Freshservice does not have a username field, the username field will always be treated as the primary email. 

Can you try removing the matching precedence for “​email�type eq work]” and only use “username” as the only matching precedence to resolve this?

Your matching precedence should look like this: