Tickets & customer support
Understand Contacts, Accounts and ticket participants
Keep customer identity, organization context, email participation and portal authorization distinct so each person sees the right work.
Distinguish the people and records
A Contact represents a customer identity. An Account groups support context for an organization or an individual. A ticket requester owns the request. A CC participant receives customer-facing email on that thread. These concepts overlap in everyday work, but they do not grant identical access.
For example, adding a colleague to an email reply can make that colleague a persistent CC recipient. It does not automatically make them an Account Administrator or let them open the ticket in the customer portal. An internal support agent is a staff identity with Department access, not a customer Contact joining an internal conversation.
Understand email identity matching
For inbound email, EleonEcho uses a usable Reply-To identity before falling back to From. It matches the normalized identity within the tenant and workspace and creates a Contact when needed. Email normalization trims surrounding whitespace, handles address case and international domain names, while retaining dots and plus-tag aliases.
Do not assume that two variations of an address have been merged because an email provider delivers them to the same inbox. Check the actual Contact association before changing Account roles or merging tickets. A quoted ticket number or message reference alone does not authorize an unknown sender to join an existing request.
When an authorized participant replies, newly observed CC addresses can become recipients for future Reply All messages. Removing a CC affects future sends; it does not rewrite who received earlier emails. See reply and participant handling before sending sensitive information.
Use Organization and Personal Accounts correctly
An Organization Account can have verified non-public domains and explicitly assigned Account Administrators. When exactly one active verified domain mapping matches the requester, the account resolver can associate that organization. If there is no match or more than one eligible match, the system leaves the Account unset rather than guessing.
A Personal Account belongs to one immutable owner Contact and identity. It has no domain ownership or Account Administrator scope. It does not give the owner access beyond their ordinary ticket ownership. Its type and owner are not customer-editable classification fields.
A tenant administrator can configure the public-email-domain policy used to create or reuse Personal Accounts. Replacing that policy affects classification; it is not permission to turn well-known shared email-provider domains into Organization domains. Keep domain ownership and support-access decisions explicit.
Review roles and customer visibility
Ordinary portal Contacts work with tickets where they are the requester. An explicitly authorized Account Administrator can work with tickets in that Account. Internal staff grant and revoke that role; the customer portal does not contain a self-service privilege upgrade.
When a customer cannot see an expected ticket, check the authenticated Contact, the requester, the Account context and current Account Administrator role. Email delivery as a CC is not a portal-access test. When a staff member cannot see the record, check Department scope separately.
Contact and ticket retention have authorized deletion workflows. Removing a Contact can affect their own tickets and their authored content in other requests, so review the exact deletion preview before committing. It does not mean deleting unrelated customers' conversations or removing messages from an upstream mailbox.
Keep social identities separate until authorized
Social Support identities are scoped to the provider and connection. A Telegram display name, WhatsApp profile or SMS phone identity does not automatically link to an email Contact, organization or portal login. Similar names across channels are not reliable evidence that the same person is authorized.
This separation matters when combining email support with messaging channels. Review the customer context exposed by the supported workflow instead of assuming that one conversation reveals all of a person's tickets. Follow social support setup for capture and channel boundaries.