Checkr Background Check Workflow Does Not Check For Email Address Before Submitting

[JimMichael]

Description

The Checkr Background Check workflow that is launched from the Actions menu on a person does not verify that the person (candidate) has any email address on their profile before submitting the request. This guarantees such requests will fail, with no obvious way for the requester to know that's what happened or how to fix/re-submit it.

Steps to Reproduce

1. Go to a person record with NO email address on file
2. Click on Actions | Background Check (this assumes the system is configured for Checkr background checks, not PMM)
3. Submit the request
4. Observe that the workflow instantly errors-out, because there is no email address for this candidate and Checkr cannot function (contact the candidate) without such address.

Expected behavior:

Because an email address on a candidate is REQUIRED for Checkr to function, the workflow should be warning the requester that no address exists for the candidate, and prevent the submission of the workflow until such an address exists (with an explanatory error)

Actual behavior:

The Checkr workflow allows the submission (request) for candidates that have no address, which instantly fail and give the requester no obvious steps for resolution. Instead, Background Check Admins get a link on their homepage that says "Background Check: [name] (Request Error)" but this link takes you to a form in the workflow where you can only re-submit it... it doesn't tell you that the error is due to a missing email address on the profile, and even if it did you still can't edit it here. The requester gets no notification at all.

It would be much easier/simpler/better to just have the workflow refuse to submit if there is no email address for the candidate, with a good error/explanation telling the requester what the problem is.

While we realize this is a pretty trivial thing to add to the Checkr workflow ourselves, we are hesitant to edit such a Core workflow for fear our modifications could break future changes to the workflow from core.

Versions

• Rock Version: All versions that have Checkr workflow

[crayzd92]

@JimMichael is this essentially the same as https://community.rockrms.com/ideas/1675? If so, we are working on getting that into 13.2 for Beta.

[JimMichael]

Yes, sorry! That idea didn't seem to be getting any traction and after this happened again multiple times recently I decided to put an issue in for it as the behavior is broken by letting you submit the form (request) without all necessary data being in place.

I guess this can be closed, then!

[crayzd92]

No worries. We will close this out once the change for the idea is in the system.

[crayzd92]

@JimMichael The idea has been updated and this is in v13.2

[JimMichael]

Perhaps I'm missing something (I hope?) but I'm struggling to see how this change in 13.2 is considered a "fix" for the issue I brought up with the Checkr background check when the candidate has no email address.

As far as I can tell, the only change was to add a Set Person Email Valid Attribute action, which determines if the Person has an email address (good) and sets a flag, and then a subsequent Person Email Valid action that simply completes the workflow if the flag is true (seriously?)

The result is that a person submitting a Checker Background check for a Person that has no email address receives this suuuppper helpful error message

that tells them absolutely nothing useful (like, "the person you are trying to submit a BGC for does not have an email address" or something similar. I never like to jump to conclusions, but again... I'm struggling to understand how this fix passed the "we implemented your useful suggestion" test. It's almost funny. Almost.

[JimMichael]

Also just wanted to clarify that the above came off harsher than I'd intended, so I apologize if it came off that way. I should know better than to post at night when I'm tired :-( I just wanted to find out why this is considered fixing the core issue of the enhancement, when (again, unless I'm missing something... which is ENTIRELY possible), it does not.

[crayzd92]

@JimMichael no worries. I am looking into your concerns with the development team and will get back to you here. In the meantime here is the code change for this request. Since it was in a migration file it didn't end up as a commit link here. We'll do better.

[dynamiclynk]

@JimMichael @crayzd92 Okay I have stood up a new 13.2 instance and it works as expected. I am researching to see why it is busted in your installation. Is this a new instance of 13.2 or an upgrade in your case?

As expected:

Actual flow:

Result:

[dynamiclynk]

I was able to repro on pre-alpha which wasn't the case before, or possibly a particular scenario is the cause. Anyways I am digging into it. I will post an update once I have the resolution.

[JimMichael]

Thanks for this info, @dynamiclynk ! So glad to know that it's broken somehow and that what I'm seeing wasn't the intended fix. To answer your question... this is an upgrade, not a new instance.

Just in case it matters or helps... after looking at our Checkr workflow I can see it's been modified slightly from stock... we added an attribute to act as a flag, and an additional action so we can launch the workflow from the Actions menu or a Connection Request.

Maybe that somehow broke the migration? But that wouldn't explain why it's also broken on prealpha (which is where I got my screen shots above from, for what it's worth).

[ethan-sparkdevnetwork]

@JimMichael I found an issue where the workflow didn't have the PersonEmailValid attribute set when checking the email. The result was that every request would say the email address was missing or invalid.

If you're still seeing incorrect functionality after 13.7 can you send me a couple of screenshots of the workflow in Edit mode:

1. The folded list of all of the actions in the Initial Request Activity
2. The Expanded view of the Set PersonEmailValid Attribute Action

If you want to test out a script I can send that to you as well.

[JimMichael]

Thanks for fixing this! We've known about it quite a while in chat and have walked several users seeing the problem through updating that action manually, but having it fixed automatically is much better ;-)