Workspace roles, permissions and staff access

Understand the layers of workspace access

EleonEcho combines shared identity services with module-specific authorization. A user may need permission to open a module, permission for a particular action and a valid relationship to the record being accessed. Tenant or workspace boundaries also determine which configuration and records belong to the current context.

Use roles to organize the responsibilities supported by your deployment. Do not assume that a role name has the same permissions in every installation. When introducing a new publishing or support process, identify who prepares work, who approves it and who administers the integration.

Use personal profile and session management

The shared user account area includes profile and session views. Use the account menu for the controls available in your deployment. Personal account settings are different from module administration: updating your profile does not add you to a support Department or grant access to an external provider.

If behavior differs between accounts, first confirm the signed-in user and current workspace. Avoid sharing sessions to work around access problems. A session that belongs to an administrator can conceal the restriction that another team member will encounter during ordinary work.

Combine Ticket Agent permission with Department membership

A Ticket Department corresponds to an organizational unit. Assignment eligibility requires an active user, Ticket Agent permission and membership in the relevant Department. A person visible in a general user search is therefore not automatically an eligible assignee.

Ticket visibility and actions are computed using the current Department and record context. Recheck membership when moving a person between teams. See Departments and routing for the operational setup, and saved views for why a filter does not grant additional record access.

Respect publishing review and AI permissions

Publishing combines management permissions with creator and reviewer visibility. Work awaiting a particular approval step should be handled by its assigned reviewer or reviser. An unrelated colleague having general publishing access does not make them the assigned approver.

AI agent management has separate capabilities for definitions, versions, publication, run history and sandbox use. Individual agents can also be read-only or restrict access. Tools operate within their own authorization context; adding a knowledge source or writing an instruction does not grant a new business permission.

Keep customer access separate from staff access

The Customer Portal uses external identity and explicit ticket access. Ordinary Contacts can see their own tickets; an explicit Account Administrator can receive the account-scoped access configured for that role. An email CC recipient does not automatically become a portal administrator or an internal conversation member.

External Forms likewise has participant-facing views with their own request and submission rules. Verify the intended participant journey instead of sending a staff administration link to a customer. Read Customer Portal access and Forms for those distinctions.

Troubleshoot missing menus or denied actions

1. Confirm the signed-in identity and intended workspace.
2. Check whether the module or feature is enabled in this deployment.
3. Check the specific action permission, not only the top-level menu.
4. Check Department, reviewer, requester or account relationships as appropriate.
5. Retry after the administrator confirms the corrected access and session state.

Provide the action and a safe record reference when requesting help. Never include passwords, authorization tokens or another customer’s private conversation as evidence of an access problem.