Ability to customize the messages shown to revoked or inactive portal‑only customers when they try to create or update requests

XMLWordPrintable

    • 1

      Summary
      Admins should be able to customise the messages shown to revoked or inactive portal‑only customers when they try to create or update requests by email, or when they use the customer portal.

      Problem
      As part of regular housekeeping, we clean up portal‑only customers and plan to revoke access for accounts that haven’t been active for a period of time.

      If those customers come back and try to contact them, they currently see generic system messages such as:

      1. New request via email – “Your request couldn't be created…”
      2. Update via email – the update is rejected because the user is inactive, with no way to tailor the message.
      3. Portal login / submit – “We couldn't submit your request. Refresh the page and try again.”

      The issue with these messages is that they:

      • Don’t explain that access was removed because the account had been inactive for a long time.
      • Don’t allow the customers to offer alternative ways to reach support (for example, email, phone, or a public form).
      • Lead to confusion and extra work for support when someone returns after several years and doesn’t understand why things aren’t working.

      Requested feature
      An option to customise the messaging shown specifically to revoked or inactive portal‑only customers when:

      • An email fails to create a new request because the sender’s portal account has been revoked or is inactive.
      • An email fails to update an existing request for the same reason.
      • A revoked or inactive customer tries to log in or submit a request through the portal.

      Ideally, admins should be able to:

      • Clearly explain why the action failed (for example, “Your portal access was removed after X years of inactivity”), and
      • Share simple, alternative contact details (such as a support email address, phone number, or external contact form).

      This configuration could live at the org or project level (for example, in Customer notifications or Help Center/portal settings).

      Value

      • Gives returning, long‑inactive customers a clear, respectful explanation instead of a confusing error.
      • Reduces back‑and‑forth for support teams by guiding people to the right contact channel straight away.
      • Helps us keep the customer access clean and compliant, while still providing a good experience for anyone who comes back after a long time.

            Assignee:
            Unassigned
            Reporter:
            G Harikrishnan
            Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: