Hi, May I know the version please?

/Subhashini  

Hi @subslk,

22.2.7 

BR/Narmada

Hi @subslk @Narmada 

same error, on 23R1, any solution that worked?

Thanks

Dominik

We got the same error when trying to install a clean Cloud environment by migrating users from an App10 environment. The cause for us was that we did not migrate addresses; so after migrating addresses we got rid of the error message. (that is, it seems that if you SCIM-provision a user that exists, it have to have an address registered.

ps.

we had 2 addresses registered for our users, so after 1 successful SCIM-provisioning, a new error appeared: {"schemas":""urn:ietf:params:scim:api:messages:2.0:Error"],"detail":"null","status":"500"}.

After deleting all addresses except 1 we can continuously provision a user.

ps2.

Even with the workaround; we noticed that registered email-addresses and phone-numbers are disconnected from the addresses they were originally connected to. eg instead of having different email-addresses connected to different addresses; after running SCIM-provisioning all comm-methods no long are connected to an address-id.

@linkri thank you for trying.

I have an open case CS0182667 where IFS confirmed a bug. waiting for an update

Hi @dominikdurrer 

Have You received any valuable output on You ticket? I am asking because we have customer on 23R2 release and SCIM configuration(Azure AD). The behaviour is very upredictible. One time user identity is ADAM967 next time ADAKAM for Adam Kaminsky. Once phone number is synchronized on the other time not. Azure privisioning logs show many errors event if we using only supported SCIM attributes follow the documentation

Index - Technical Documentation For IFS Cloud

When user is removed from AD group then on IFS side sometimes is not removed, etc. Last one problem is most important because we manage permissions through the user groups.

I spent many hours but still do not understand it and predict behaviour. Is seems that provisioning on demand is a bit different than automatic provisioning.

I need any kind of help to be closer with understanding this. 

Hi @knepiosko 

Planned versions of fixing this issue according to IFS support for my case CS0182667 is:
22.1.23 - 22R1 SU23
22.2.16 - 22R2 SU16
23.1.9 - 23R1 SU9
23.2.2 - 23R2 SU2
24.1E.0 - 24R1 EA

I have not managed a single user to sync. We sync address type ‘WORK’ as well as use field Initials containing the person ID to match the cycle from IFS employee file to AD → AAD → back to IFS. User Identity appears to be correct, we use firstname.lastname

I have not even yet tried with the AAD groups, but its also important for us that they manage the permission sets.

Dear all

23R2 SU02 applied but still same error. Ticket reopened. Anybody successfully implented SCIM from an existing Apps10 DB?

Thanks

Dominik

Dear all

I finally managed by deleting all default attribute mappings and sticking to just the bare minimum described here:

Index - Technical Documentation For IFS Cloud

will gradually try to increase the amount of information, especially address and communication methods.

Thanks

Dominik

@dominikdurrer  were you able to map the Identify and person properly? we are trying to use SCIM with 23R2 and Entra ID (Azure AD) and we get random results in both fields. 

@Curious_User I was not, and it’s confirmed by support that this is not how it was designed.

Looking for other customers where this is important to escalate the ticket for urgent development of this functionality.

at this stage I would highly avoid SCIM sync.

we noticed that it deletes employees private and work addresses, but even if just job title changes and is in the sync, firstname and last name gets deleted!

3rd case now open with IFS.

Thank you @dominikdurrer , We are on 24R1 and same issues persists, looks like we will also stay away from the SCIM function until further notice. Thank you for further looking into it and providing an update.