EOTI. But Make it Safe!
EOTI. But Make it Safe!
Everyone on the Internet. This phrase can elicit so many emotions.
For many of our clients, they get the feeling of relief. ‘Finally! A way that we can allow OUR clients to access Quickbase directly for order entry!’
For me, a developer who was highly involved in SOC auditing processes at my last company, it leaves me with a deep sense of unease.
There’s obviously an appetite for allowing EOTI! There are many use-cases where it’s considered necessary. But it’s not without risks. One of your company’s most precious commodities is its data. You don’t want your clients stumbling across another client’s data, or data they should not be accessing.
One of my first forays into the world of EOTI was when I was charged with coming up with a solution to allow external applicants to submit their resume to our HR department. Obviously HR had their own Quickbase application for managing the interview process and transitioning applicants into employees. It was absolutely out of the question to open our HR application to everyone on the internet.
‘But you can control it, right?’ Yes! You can absolutely control what the EOTI role sees in your application. My concerns ran deeper. If we were to add a new table in the HR application, and bring over sensitive information from employee records…the table would default to ‘VISIBLE’ for all roles. While I knew that, other builders may not, they may inadvertently expose data and cause a public embarrassment for the company.
But removing the threat (EOTI) was not an option since it was the very thing I needed to make this work!
My solution? I created a new application. This application would consume data, but not store it. Back in those days, we didn’t have awesome stuff like Pipelines, so it was straight API. But these days Quickbase has made it even easier to pull off this pattern.
I created some formula fields that would build URLs for my HR team to use in their job postings. These URLs pre-filled some hidden fields such as where the applicant saw the listing (Indeed, Monster, etc), as well as the actual position they were applying for.
- EOTI role has ADD RECORD permissions only, they cannot view records.*
- Applicant clicks the link and is brought to a new record in the ‘capstone’ application.
- They fill out their information and submit.
- Pipeline is triggered to read the record, create a new record containing the data in the actual HR application, and then return to the original record and delete it out of the app.
This ensures that sensitive data is never actually exposed to EOTI. Since the intake app is not used for any other purpose, we don’t have to worry about obsessively checking the EOTI role when new tables or fields are introduced to ensure it doesn’t get access!
Since the EOTI role only has access to add, the deletion of records could also be a nightly scheduled Pipeline depending on the activity and concurrency expected in the application.
*This pattern obviously does not allow for applicants to save their application and finish it later. There is not a 100% secure recommended pattern for allowing EOTI users to find and edit records.
