Troubleshooting: confirm the existing identity
Search the authorized client list for the exact intended email and organization before assuming the invitation failed. A typo, alternate address or existing account can explain why the recipient cannot use the expected message. Do not create another client identity as the first troubleshooting step. Duplicate identities can fragment requests and access history, leaving the customer unsure which account contains their work and which invitation is current.
Use the documented recovery carefully
ManyRequests documents an invitation-resend path through the client menu’s Reset Password action. That wording can be surprising, so verify the current help article and the exact target before using it. A password-related action should not be treated as an invisible background fix for the wrong person. Tell the intended recipient what recovery message to expect, and do not request that they send you their password or access-bearing link.
Check access after the handoff
Once the client completes the supported recovery, confirm that they can see the correct organization and request. An email being sent is not proof that access works. Avoid using an administrator’s broad view as evidence of the client’s actual experience. Where appropriate, ask the client to confirm a non-sensitive visible detail, or use an approved test account for a rehearsal instead of impersonating an unrelated real customer.
Preserve the original work
Keep existing requests, comments and approvals attached to their original records. If two identities already exist, do not merge, delete or reassign them casually without understanding the supported consequences. Record the issue and use the provider’s documented process. The goal is restored access with continuity, not merely a fresh invitation. A successful recovery should leave the client able to continue the same work without re-entering briefs or reapproving completed decisions.
Sources used for this page
These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.
- ManyRequests invitation recovery — Merchant documentation · help.manyrequests.com · Merchant-controlled · checked 2026-09-19
- ManyRequests client management — Merchant documentation · help.manyrequests.com · Merchant-controlled · checked 2026-09-19
- ManyRequests admin, client and team permissions — Merchant documentation · help.manyrequests.com · Merchant-controlled · checked 2026-09-19