One-Click Manager Approval from a Quickbase Email (Approve and Deny Links)

A question in the Quickbase community asked how to let a manager approve a request straight from an email (original thread here). The table had a Yes/No approval field and a "Manager Approval Status" that shows Pending, Approved or Denied. The goal was to email the manager when a request comes in and let them click Yes or No right in the email, without opening a form and hitting Save.

One reply suggested a link that opens the record in edit mode on a specific form. That works, and I mention it again at the end. But you can make it a true one-click action: two Formula - URL fields that each set the approval field through API_EditRecord, then send the manager back to the record so they can see the result.

I built this in a sandbox app with a small Time Off Requests table to check it. The formulas below are copied from that build, and I ran each link to confirm it really updates the record and redirects. The names and dates are made up.

What we're working with

My test table, "Time Off Requests", has these fields:

The status field is just a formula on top of the approval field:

If([Manager Approval] = "Yes", "Approved",
   [Manager Approval] = "No", "Denied",
   "Pending")

If you already have a status field that works differently, that's fine. The links only need to set the field the manager would normally set by hand.

Step 1: Find the field ID of the approval field

The link sets the field by its ID, not by its name.

1. Open the table's settings and go to Fields.
2. Find your approval field (Manager Approval here) and read the number in the ID column.

In my table it was 11. Use your own number everywhere you see _fid_11 below.

Step 2: Create the Approve field

Add a new field to the table:

• Type: Formula - URL
• Name: Approve

Paste this formula:

URLRoot() & "db/" & Dbid()
  & "?a=API_EditRecord&rid=" & [Record ID#]
  & "&_fid_11=Yes"
  & "&rdr=" & URLEncode(URLRoot() & "db/" & Dbid() & "?a=dr&rid=" & [Record ID#])

Here's what each piece does:

• URLRoot() & "db/" & Dbid() builds the address of this table in your own realm, so you don't hard-code anything.
• a=API_EditRecord&rid= plus [Record ID#] tells Quickbase to edit this one record.
• _fid_11=Yes is the change: put "Yes" in field 11.
• rdr= is where to send the browser after the edit succeeds. Here it's the same record in view mode (a=dr), so the manager sees the updated status instead of a page of raw XML.

On the field's properties, set the link text to Approve so people see a word instead of a long URL.

For record 1 in my sandbox, the formula produced:

https://webapp.quickbase.com/db/<table id>?a=API_EditRecord&rid=1&_fid_11=Yes&rdr=https%3A%2F%2Fwebapp.quickbase.com%2Fdb%2F<table id>%3Fa%3Ddr%26rid%3D1

Why URLEncode() matters

The redirect address has its own ? and & in it. If you paste it in as-is, Quickbase can't tell where the rdr value ends and the next parameter begins, because the &rid= inside the redirect looks like a second rid for the edit itself. With URLEncode(), those characters come out as %3F, %3D and %26, and the whole redirect is treated as one value.

I tried it both ways. The encoded link edited the record and redirected cleanly. The unencoded one failed with an error and the record didn't change.

Step 3: Create the Deny field

Make a second Formula - URL field called Deny. It's the same formula with No instead of Yes:

URLRoot() & "db/" & Dbid()
  & "?a=API_EditRecord&rid=" & [Record ID#]
  & "&_fid_11=No"
  & "&rdr=" & URLEncode(URLRoot() & "db/" & Dbid() & "?a=dr&rid=" & [Record ID#])

Set its link text to Deny.

Step 4: Check whether your app needs an app token

Some apps require an application token on every API call, including calls made from a link like this. My sandbox app does. When I opened the link with no credentials at all, Quickbase answered with:

<errcode>24</errcode>
<errtext>Invalid Application Token</errtext>
<errdetail>An Application Token must be supplied.</errdetail>

If your managers see that error when they click, you have two choices:

• Add the token to the link. Create one in the app's settings under App management > Manage Application Tokens, then add & "&apptoken=YOUR_TOKEN" to both formulas, right after the _fid_11 part. An app token isn't a password. It only works together with a signed-in user, so it's fine for it to appear in the link.
• Turn the requirement off. In the app's settings under App properties, clear Require Application Tokens. Only do this if nothing else in your app depends on it.

Whatever you do, never put a user token in these links. A user token signs in as you, and emails get forwarded.

Step 5: Build the email notification

1. In the table's settings, open Notifications and create a new notification.
2. Notify whom: pick the Manager user field, so each request goes to the right person.
3. When: choose when records are added. If you also send it on modify, add a condition such as "Manager Approval is blank". Otherwise the click itself modifies the record and the manager gets a second email (see the tips below).
4. Message type: Custom message. Choose HTML for the message format, so the links show their link text.
5. Write the message and put the two fields in it with square brackets, like any other field:

[Employee] has asked for time off from [Start Date] to [End Date].

Reason: [Reason]

Approve this request: [Approve]
Deny this request: [Deny]

Here's roughly what the manager gets:

Step 6: Test it

1. Add a test request (in my sandbox: Sarah Lee, Thanksgiving trip) and assign yourself as the Manager.
2. Open the email and click Approve.
3. Your browser lands on that record. Manager Approval shows Yes, and Manager Approval Status shows Approved.
4. Add a second request and click Deny. You should see No and Denied.

That's what happened in my sandbox: each click returned a redirect straight to ?a=dr&rid= for that record, and the record showed the new value. Sarah Lee's request went to Approved and Mike Chen's went to Denied. A third request from Priya Patel that nobody had clicked yet stayed at Pending.

What the manager needs

The link isn't a back door. It does exactly what the manager could do on the form, with their own permissions:

• They have to be signed in to Quickbase in the browser the email opens. If they aren't, they get the sign-in page first. If they end up on the app's home page after signing in, they can just click the link in the email again.
• Their role needs permission to edit the approval field. If it doesn't, the click fails and the record stays as it was.
• The change is saved under their name. Last Modified By shows the manager who clicked, and so does field history if you've turned it on for that field. That gives you an audit trail of who approved what.

It's also worth checking the other side: if employees can edit Manager Approval on their own requests, they could approve themselves. Lock that field down for the employee role in the field's permissions.

Tips and variations

Avoid the double email. Clicking Approve is a record change. If your notification fires on any modification, the manager gets a fresh email right after approving. Send it only when a record is added, or add a condition that only matches while the decision is still empty.

Only show the links while a request is pending. Wrap each formula in an If() so the field is blank once there's a decision. In my sandbox this returned the link for the pending request and an empty value for the two that were already decided:

If([Manager Approval] = "",
  URLRoot() & "db/" & Dbid()
    & "?a=API_EditRecord&rid=" & [Record ID#]
    & "&_fid_11=Yes"
    & "&rdr=" & URLEncode(URLRoot() & "db/" & Dbid() & "?a=dr&rid=" & [Record ID#]),
  "")

This keeps the links off the form once a request is decided. It doesn't change emails that were already sent, though, because the link in an old email is fixed when the email goes out.

Set more than one field. Add more &_fid_X= pairs. If a value can contain spaces or symbols, wrap it in URLEncode(). For example, to also set a text field (ID 20 in this example) to "Approved by email":

& "&_fid_20=" & URLEncode("Approved by email")

Land somewhere else. The rdr value can be any Quickbase page. Point it at a report of the manager's pending requests, for example, so they can work through a list.

When the manager should add a comment. For denials, you may want a reason. That's where the edit-form approach from the thread fits: a link like URLRoot() & "db/" & Dbid() & "?a=er&rid=" & [Record ID#] & "&dfid=12" opens the record in edit mode on a small form (form 12 here) with just the approval field and a comment box. You could use one-click Approve and form-based Deny in the same email.

Summary

• Make two Formula - URL fields that call API_EditRecord on this record and set your approval field (&_fid_<id>=Yes and &_fid_<id>=No).
• Add &rdr= with a URLEncode()'d link back to the record (?a=dr&rid=), so the click ends on the record and not on raw XML.
• If your app requires application tokens, add &apptoken= to both links or turn the requirement off. Never put a user token in a link.
• Put [Approve] and [Deny] in a custom HTML email notification addressed to the Manager field, and don't let the click retrigger the same email.
• The manager must be signed in with permission to edit the approval field. The change is recorded under their name.