GravityKit: the support team that built the access tool it needed
A ticket arrives overnight and nobody can see the site
A GravityView ticket comes in overnight. The reported bug is real, but the description alone isn’t enough to diagnose it. Someone needs to see the actual site: the form configuration, the theme conflict, the specific view settings the customer built. There’s no way to know without logging in.
GravityKit tracked what that used to cost, ticket by ticket, on its own support queue:
- The customer submits the ticket overnight. Elapsed: 8 hours.
- Support reads it, confirms a site login is needed, and emails the customer asking them to create one. Elapsed: 8 hours 15 minutes.
- The customer replies with a login, hours later. Elapsed: 12 hours.
- Sometimes the login doesn’t work: a typo, a wrong role, a plugin that blocked the new account. Another round of emails. Elapsed: 16 hours.
Four emails and most of a working day, and the bug hadn’t been touched yet. That’s GravityKit’s own support data, not an industry estimate.
The login request now lives in a product the customer already installed
GravityKit builds GravityView and its add-ons for Gravity Forms. Foundation, the shared library every GravityKit plugin runs on, has the TrustedLogin SDK (trustedlogin/client ^1.10) built in: the code that puts the access button inside a plugin. Every GravityKit plugin therefore ships a Grant Support Access screen inside the plugin itself, with no separate download.
A ticket that needs a site login now runs like this. The agent asks the customer to click Grant Support Access inside their GravityView settings. The customer clicks it, and the click is still theirs to make. The customer sees what they are agreeing to before they agree to it: the role and the time limit GravityKit set once, for every request that plugin makes, rather than a menu to pick from. What travels afterward is sealed, so a support login is not something the customer has to take on trust. The handoff is encrypted before it leaves their site, and only GravityKit’s own Connector plugin holds the key that opens it, on GravityKit’s infrastructure rather than on TrustedLogin’s servers. The full exchange, from the customer’s click to the agent’s login, is written up separately.
From there, the agent logs in straight from the Help Scout sidebar, next to the ticket. No separate dashboard tab, no copying a URL between windows. When the ticket closes, access expires on its own, on the schedule GravityKit configured. Nobody sends a follow-up email asking the customer to change their password back, and no standing account is left behind to remember to delete.
2,589 support logins across 1,789 customer sites
| Metric | Value |
|---|---|
| Support logins (since August 2024) | 2,589 |
| Customer sites granted access | 1,789 |
| Logins in the last 90 days | 114 |
| Emails needed per login | 0 |
The event store TrustedLogin uses to log logins only starts in August 2024. GravityKit had already been running this flow before that, but that is as far back as the record goes.
A support agent’s day now
A ticket needing site access arrives in Help Scout. The agent replies asking the customer to click Grant Support Access from inside GravityView’s settings, with a one-line note on where to find the button. The customer clicks it. A “Log in” link appears in the Help Scout sidebar next to that conversation. The agent clicks it, lands in wp-admin already authenticated, reproduces the bug, and replies with a fix or a follow-up question in the same ticket, with no tab-switching and no second thread asking “did you get my email.” When the grant’s window closes, the account is gone from the site’s Users list on its own.
The role and duration are fixed, and the audit trail stops at 90 days
TrustedLogin doesn’t turn every ticket into a custom access request. The role and duration a customer sees are fixed at the plugin level, set once when GravityKit configured the SDK rather than chosen per ticket. An agent who needs Administrator for one ticket and Editor for the next doesn’t get to ask for that; they get whatever GravityKit’s GravityView integration was built to request, every time.
The audit trail (who logged in, to which site, when) is kept for 90 days. Older sessions aren’t retrievable.
And the customer still has to click. Nothing about this removes their consent from the loop or logs an agent in without them knowing. If a customer doesn’t respond to the request, the ticket waits exactly as it did before, just without a password changing hands in the meantime.
Why GravityKit built this instead of using a temporary-login plugin
Free options exist for one-off cases: a plugin the customer installs, generates a login, and deletes when they’re done. GravityKit’s support team faces the same request across its entire install base, week after week, and a one-off tool doesn’t hold up at that scale.
A temporary-login plugin is one more thing to ask the customer to install before troubleshooting can start, so the ticket that needed a login now needs a second plugin too. GravityKit’s agents also needed one record across every grant, rather than a login history scattered across whichever plugin each customer happened to install, in whichever version. And standing access was the thing to avoid entirely: an account a support hire creates and nobody remembers to remove is exactly the kind of unmanaged credential that turns into an incident later. Building access into the product GravityKit already ships meant every customer got the same request, logged and expiring the same way, without a second install standing between the ticket and the fix.