Accept/Reject Notification without having to signin

We cover things like this in our "Office Hours" webinars, held each Tuesday and Friday at 1pm Eastern time. 

To register: http://quickbase.com/webinars/

Hey Ryan - if the users are in Quick Base and logged in, it is up to your mail client/browser to retain the session. For example, I often click links from Outlook and remain logged into QB. If the users are't QB users... you can achieve this with a custom everyone on the internet (EOTI) implementation. You would first want to evaluate the risk internally of the type of data you are putting at risk but it can be done. The role needs to be managed carefully. Would look something like

1. Setup a log status table. Two reasons:
   1. This is more scalable than having it as individual fields because you can have a log and analyze the content.
   2. It also reduces the blast radius of any security issues, since your approval/rejections would be record adds to a table which is safer than allowing modifications with tight permissions.
2. Add a role that has EOTI abilities and use least-privilege model to setup only the permissions you need.
   1. This is likely just "add" permissions on the new table. Quadruple check it doesn't have view, delete or modify on any other tables.
   2. Strip down the UI properties to have no tables, reports, buttons, etc.
   3. Do custom field permissions removing access from all fields you can.
   4. Any other necessary cleanup to keep it as lean as possible.
   5. Set a blank dashboard, or one that has a rich text component like "Thank you for your submission."
3. Create a formula-url that does an approve and one for reject. They should tie to the parent record via reference field.
   1. Because the users are not authenticated, there is no way for you to actually know who pushed the button.
   2. Redirect the user to your blank or custom dashboard that should be extremely lean.
4. Include these in your email.

The only attack vector here is someone maliciously adding records to the logs table. One way to reduce the opening there is using Custom Data Rules (CDR) to not allow the record to be added unless it has the necessary parameters passed in, like a "Related...". If you are really worried about the security, you could consider a staging application that is used for you to write the approval/rejection records to, kind of like a message queue. From there, an Automation or Webhook could push the data to production. This approach will reduce the attack possibilities by a wide margin since EOTI won't exist in your main app.

You'll want to stay away from approaches that suggest embedding authentication in the button because these are easily compromised. If you need more customization, you could put a small server-side script into the process here that authenticates with an intranet, IP filtering, or something similar and have your script manage the API calls to Quick Base.

Hope this helps.