ARS Upgrade to 8.0 workflow approvals that request information causes error

I have no answer on the question. Maybe my recent observations will help alittle. Unfortunately, I have seen the same error "Object reference not set to an instance of an object" on ARS 7.6.1 recently after upgrade (from 7.3.1). I think there was much coding changed on backend and I had the following unfortunate discoveries, so far.

1) error "phase" reporting might change.

2) I found that *msExchHideFromAddressLists* is not treated as flat ldap AD attribute anymore, but in compliance with "Exchange Rule" and cannot be set on AD user without email (contact or mailbox).

3) ARS Sync cannot set $null on AD attribute, instead need to use Sync Consol UI option <clear> (But I have a custom code returning value A,B,C,$null) (it seems like, I need to do additional testing). In case the #3 confirmed, it will impact all my Sync PS1 custom codes returning A,B,C...,$null.

Thank you for the response, Aidar.

This is actually a big issue for us.  We use workflows that request information from the "Approver's" for things such as employee badge number, DID's, Two Factor hardware token ID's, etc.  Since the approvers are now unable to enter in this information into the requested attribute, it affects downstream workflows (notifications that recall those attributes) to our onboarding and training staff. 

What is the best course of action to getting a hot fix for ARS 8.0?  The 7.4.3 version we were on is on limited support, which is why we did the upgrade.  Otherwise, I'm a firm believer in, "If it isn't broke, don't fix it" (unless there is a vulnerability, in that case I consider it broke)!  We have been running ARS 8.0 for about a week now.  I'm thinking that it might be more harmful to roll-back now that we have had a couple hundred transactions since the upgrade.  I'll file a support request for this issue, but I assume others maybe having this issue too.  What is the process to getting a hot fix developed for this issue?  Wondering if One Identity needs a certain number of tickets before this is put on the project list.

Thanks in advance for any advise.

Thank you for the response, Aidar.

This is actually a big issue for us.  We use workflows that request information from the "Approver's" for things such as employee badge number, DID's, Two Factor hardware token ID's, etc.  Since the approvers are now unable to enter in this information into the requested attribute, it affects downstream workflows (notifications that recall those attributes) to our onboarding and training staff. 

What is the best course of action to getting a hot fix for ARS 8.0?  The 7.4.3 version we were on is on limited support, which is why we did the upgrade.  Otherwise, I'm a firm believer in, "If it isn't broke, don't fix it" (unless there is a vulnerability, in that case I consider it broke)!  We have been running ARS 8.0 for about a week now.  I'm thinking that it might be more harmful to roll-back now that we have had a couple hundred transactions since the upgrade.  I'll file a support request for this issue, but I assume others maybe having this issue too.  What is the process to getting a hot fix developed for this issue?  Wondering if One Identity needs a certain number of tickets before this is put on the project list.

Thanks in advance for any advise.

This seems like a pretty big deal for your organization.  I would recommend you proceed as follows:

1) Log the details of the issue into a ticket via the Support portal - this will save "20 questions" later.

2) With SR # in hand, CALL into Support and tell them you would like this escalated as a Sev 1.

Thank you, JohnnyQuest.

I have done as you recommended.

For reference:

"Technical Support | Case Number: 01938243 | all approvals that require a request of info are throwing an error"

You're quite welcome.  If it ends up that there's no solution on the immediate horizon, I can suggest an alternative way of meeting your use case that would involve some minor, entirely out-of-the-box customization of the AR Web UI.