🧑‍💻 Impersonating Applications

If you have the Person Impersonate permission, you can impersonate an application, but like Icarus, this may have you and the users in your Slate instance flying too close to the sun.

Impersonating an application is tempting. Before institutions launch their first application in Slate, impersonating applications is an easy tool for testing the application experience. And after you launch, the “Impersonate an Applicant” Knowledge Base article from Technolutions says the following:

It is helpful to impersonate an applicant when:

Testing that application pages and conditional logic show or work as expected

Testing submission requirements to ensure they are behaving as expected from the applicant point of view

Replicating an applicant's experience

But there are other, better ways of accomplishing these items without taking on the risks of impersonating someone’s application.

Risks - If your application has internal fields, impersonating applications can cause these fields to be unset. Additionally, users may accidentally change or remove information provided by the applicant on the application.

• Testing that application pages and conditional logic show or work as expected

  • Do this in your test instance! You have it for a reason. Once your application is live, you’re better off testing configuration updates in your test instance and updating your production instance to match test, if needed. There you can mimic all the unexpected ways applicants could interact with your application without impacting real data.

  • You can also do this using a test record in your production instance, but what happens when you realize something isn’t working as you expected? If you do this in production, you risk making updates that break the application experience for others when attempting to resolve a particular applicant’s issue.

• Testing submission requirements to ensure they are behaving as expected from the applicant point of view

  • There are faster and safer ways of testing these.

    • For an individual applicant, you can access their application record and select the “In Progress” link to see any hard fails (aka. submission requirements) currently listed for the application.

    • To test new or updated hard fails in bulk, build a query using the same filters that are on the hard fail in order to see which records are part of the query results.

• Replicating an applicant's experience
  • Testing in your test instance, time warp, clean Slate or even using a test record in your production instance would all be safer ways of accomplishing this than impersonating a real application in production.

Some institutions may also be in the habit of updating application fields via impersonation. The best practice for this process is to create a Custom Tab for administrative updates to application fields.

Conclusion

We do a lot of troubleshooting in Slate and often when tracking down an issue we access a record’s timeline and see that a staff member accessed the record right before the issue occurred. Mistakes will happen, but avoiding impersonation will help cut down on these unintentional errors.