Gravity Forms 3.1 adds integration with the WordPress Abilities API. The new surface can make supported operations easier for automation and tools to discover, but discovery, execution, entry access, sensitive fields, and mutations still need explicit capability checks. Custom roles, application passwords, AI assistants, workflow tools, and server integrations can expose gaps that administrator-only testing misses. A release audit maps each ability to actor, purpose, input, output, personal data, mutation, log, rate, rollback, and owner.
Use this for sites adopting Gravity Forms 3.1 with custom roles, REST integrations, application passwords, automation tools, AI-assisted administration, or forms containing health, financial, employment, or other sensitive data.
Quick answer
Inventory the registered Gravity Forms abilities and classify each as discovery, read, export, configuration, submission, deletion, or other mutation. Test unauthenticated, subscriber, contributor, editor, form manager, administrator, API key, and application-password callers. Use fixtures for own and other forms, sensitive and ordinary fields, missing input, malformed input, replay, and rate pressure. Denied responses must reveal no entry data or internal secrets. Authorized actions need actor, ability, target, decision, result, and UTC audit evidence, plus a rollback for mutations.
What to check first
- Export every registered Gravity Forms ability with its name, purpose, input schema, output fields, capability callback, mutation scope, and owning plugin version.
- Build a caller matrix for unauthenticated users, standard roles, custom form roles, administrator, application passwords, service accounts, and automation tools.
- Test own and other forms, ordinary and sensitive fields, draft and active forms, missing and malformed input, replay, expired credentials, and rate pressure.
- Inspect responses and logs for entry data, email, phone, tokens, file URLs, stack traces, SQL, capability names, or configuration details after denial.
- For each authorized mutation, record before and after state, actor, target, reason, rollback, downstream actions, and final verification.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Ability discovery | Unauthenticated caller | Only intended metadata or denial |
| Entry read | Custom form role | Only authorized form and fields |
| Configuration change | Editor versus administrator | Mutation follows capability contract |
| Automation replay | Same request ID | Idempotent or safely rejected |
Decision rule
Approve an ability only when its caller, target, fields, mutation, denial response, audit record, rate behavior, and rollback match a documented least-privilege contract.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Inventory abilities and data scope
- Write the caller capability matrix
- Run negative and sensitive-data fixtures
- Minimize logs and credentials
- Verify mutation rollback and idempotency
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Inventory abilities and data scope | Export every registered Gravity Forms ability with its name, purpose, input schema, output fields, capability callback, mutation scope, and owning plugin version. | Every ability has an owner, purpose, caller set, data scope, and capability decision. |
| Write the caller capability matrix | Build a caller matrix for unauthenticated users, standard roles, custom form roles, administrator, application passwords, service accounts, and automation tools. | Denied callers receive no entry, configuration, token, path, or stack-trace leakage. |
| Run negative and sensitive-data fixtures | Test own and other forms, ordinary and sensitive fields, draft and active forms, missing and malformed input, replay, expired credentials, and rate pressure. | Authorized mutations create minimal audit evidence and can be reversed safely. |
| Minimize logs and credentials | Inspect responses and logs for entry data, email, phone, tokens, file URLs, stack traces, SQL, capability names, or configuration details after denial. | Application passwords, service accounts, retries, and rate limits follow the written contract. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
ability,actor,target,decision,result,audit_data
gf/forms/read,form-manager,form-22,allow,200,ids-only
gf/entries/read,editor,form-22,deny,403,no-entry-data
gf/forms/update,automation,form-22,allow,200,change-id
gf/forms/update,automation,form-22,replay,409,request-id
Production verification checklist
- Every ability has an owner, purpose, caller set, data scope, and capability decision.
- Denied callers receive no entry, configuration, token, path, or stack-trace leakage.
- Authorized mutations create minimal audit evidence and can be reversed safely.
- Application passwords, service accounts, retries, and rate limits follow the written contract.
Why this usually happens
- Ability discovery is confused with authorization to execute the operation.
- A broad Gravity Forms capability grants more forms or entry fields than the automation needs.
- Application passwords are attached to administrator accounts for convenience.
- Audit logs store full inputs or outputs and create a second copy of sensitive entry data.
Field notes
- Write the expected result before changing anything and keep one repeatable canary fixture for the full test window.
- Record exact versions and UTC timestamps because caches, retries, scheduled actions, and deployments can change the evidence between checks.
- Test the public browser path and the stored server-side result, not only an admin preview or isolated API response.
- Close the task only after the visible workflow, logs, stored record, and relevant downstream system agree.
Mistakes to avoid
- Changing production before recording the exact version, request, UTC time, fixture, and rollback point.
- Treating one successful browser view as proof while logs, stored records, background jobs, and downstream systems remain unchecked.
- Testing a different role, cache state, locale, form, order, device, or integration path from the one users actually reach.
- Leaving debug output, temporary exclusions, test accounts, broad permissions, or helper code active after the verification window.
What to tell the client or owner
Give the owner a concise evidence packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key logs, change made, rollback point, final result, owner, and next review date. Remove credentials and personal data before sharing it.
Questions teams ask during testing
Should I test this directly in production?
Start with read-only evidence and reproduce on staging when the change affects code, security, checkout, forms, indexing, or permissions. If production is required, use one named canary, a short monitored window, and a tested rollback.
How do I avoid a false positive?
Repeat the same fixture with the same versions, URL, role, locale, cache state, and downstream integration. Compare stored evidence and logs instead of relying on a visual impression.
What evidence should I keep?
Keep UTC time, exact versions, URL or record ID, expected result, actual result, relevant log lines, change made, rollback point, owner, and final verification. Redact credentials and personal data.
When should I escalate?
Escalate when the site is unavailable, security scope is unclear, checkout or lead capture is affected, several systems disagree, or the next action could destroy evidence.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP audit Gravity Forms automation permissions.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references