This article contains content about advanced functionality within the Evident platform. If you have not already familiarized yourself with base functionality, we recommend doing so first. Base functionality is sufficient for the majority of use cases and scenarios that you will encounter as an Evident customer. That being said, there may be some scenarios where you need to employ more advanced features of the Evident platform. To be able to fully leverage these advanced features, a deeper understanding of the Evident platform and of your own integration is required. The purpose of all the articles in the Advanced Functionality series is designed to help guide you to this deeper understanding.
Why are constraints and the re-run verification feature referenced together so frequently?
The Re-Run Verification Feature actually leverages constraints to create a verification that ignores all the inputs or outputs that were created for a particular user. Therefore, using the re-run verification feature is using constraints.
We've already explained how usually a request called a "request" because:
-
-
- You request information from the user (via email)
- You request permission to run the verification (via explicit or implicit consent)
- You request Evident generate a billable event
- You request the Evident platform un-encrypt certain attributes for you to se
-
Special Considerations for Requests with the Re-Run Verification Feature/Constraints
Here is how this works for request created with constraints/the re-run verification feature.
Will the user have to upload new information? The Re-Run Verification feature creates a special kind of request that ignores all the previously submitted information. This means your user will have to upload any new pieces of information required to complete the new request, including documents or images. The primary mechanism of the re-run verification is to force new uploads from the user.
Will the user receive an email?
We've already mentioned how each request created in the Evident product by default sends out an email notification. But what if I don't want my user to know that I'm accessing her date of birth because it is unnecessary for her to be aware of this information? Whether or not your user actually receives an email will be governed by a either your notification preferences in the account or the notification preferences of your template, depending on how the request was created.
Specifically, if you create a request with constraints using an attribute-based integration (most common), then your notifications settings in the account will determine if your user receives an email. If you create a request with constraints by using the Re-Run Verification feature, then whether or not your user receives an email will depend on the preferences associated with the template that was used to create the initial request. You can read more about notifications here.
If the user doesn't receive an email, how does Evident treat consent?
Earlier, we mentioned that when you create a "request" in the Evident platform, the request looks for either implicit or explicit consent from the user for running the verification. Explicit consent is provided when the user is presented with language that informs them about the action that is being taken (i.e. running a background check). Implicit consent is provided when the individual submit information associated with any individual request. When we've already received a prior submission from a data subject, the request requires that someone accesses the submission page in order to provide 'implicit consent' to process the verification. You can read more about the requirements for a request here.
Will the request be billed?
Yes, in the majority of scenarios creating a request with constraints will generate a new billable event. You can read more about how billing works here.
Does the platform still un-encrypt certain attributes for me to see?
Yes, the new attributes will be encrypted and unencrypted as usual.
When and how should I use constraints/the Re-Run Verification Feature?
If more than 6m have passed since the verification was created, we recommend refreshing the results by using constraints/the re-run verification feature, on a request that contains the service attribute. For an identity verification, that means you'll usually need to use constraints/the Re-Run verification feature on the initial request that contains the "status" attribute. For a background check, you need to run constraints/the re-run verification feature on a request that has the word "profile."