Tigy permissions: who can edit, test and review agents?

Map responsibilities

List owners for prompts, documents, tools, telephony and call review. Record each person’s task and required resource. Use this map when granting access instead of assuming a role name enables every action.

Invite to the right workspace

Open the workspace people area, create the invitation and check email, role and form permissions. Track invitation status and ask the person to accept using the correct account. A pending invitation does not establish effective access.

Verify agent permissions

Owner, administrator and member roles coexist with resource permissions. Check the interface’s available actions. Testing, reviewing records and changing tools are different responsibilities; validate the needed combination with the person’s account.

Investigate rejection

Check signed-in account, accepted invitation, selected workspace and requested resource. Read access does not imply editing. Record the rejected action without sharing passwords, tokens or call data in a public channel.

Review team changes

When a responsibility ends, adjust or remove access in the people area. Review account-dependent integrations first. Removing a member and deleting a workspace are different operations: preserve resources the team still needs.

How should access differ for reviewers and maintainers?

A call reviewer may need to inspect records; an instruction maintainer needs to edit the relevant agent. Workspace administration and credential changes are additional responsibilities. Use combinations available in the interface rather than inferring a fixed permission matrix from role names alone.

For each person, record the task, resource and required action. Test one permitted action and another that should remain restricted. When access is refused, check account, accepted invitation, workspace and resource before broadening administrative access. This verifies effective access.

Describe the work before choosing a role

Permissions should follow concrete responsibilities. A quality reviewer needs to locate conversations and understand outcomes. Someone maintaining an agent needs to edit relevant instructions and sources. An integration owner may need to change tools or credentials. Billing administration is another responsibility. Giving everyone broad identical access simply because they work in operations ignores those differences and makes effective access harder to review.

On a fictional team, an analyst reviews calls for incorrect answers. They do not necessarily need to modify write tools. A colleague maintaining a calendar integration needs the relevant action, but that does not imply responsibility for administering the entire team. Use available interface options to connect tasks with access. Tigy documentation describes roles such as owner, administrator, and member alongside resource permissions; check the effective summary in the product.

Create a simple person-task-resource matrix. Instead of “needs access,” write “review runs for this agent” or “edit documents used by this service.” Specificity prevents upgrading an account role merely to fix a rejected action whose cause is still unknown. It also explains why someone may enter a workspace without being able to edit a particular agent. Workspace membership and resource maintenance are related but separate decisions.

Record ownership of the access decision and conditions prompting review. Role changes, project endings, and integration changes are useful moments. The matrix should represent current work rather than accumulate every permission previously granted. The aim is allowing each person to perform their responsibility clearly while preserving coherent limits for actions outside that operational responsibility. Verify actual access through the relevant account instead of assuming a role label fully explains every resource action.

Track invitations and confirm the account used

A sent invitation still needs acceptance by the correct account. Check that stage before investigating edit permissions. Documentation describes opening the workspace's people area, entering an email, selecting offered role and permissions, sending the invitation, and tracking state. If someone accepts using another account or enters another workspace, an apparent resource restriction may actually originate in incorrect identity or context.

In a fictional example, staff invite a colleague through a professional email, but she tests with a personal account already signed in. First verify active identity and the corresponding invitation. Do not solve the mismatch by giving the personal account administration without evaluating the objective. Preserve the relationship between person, account, and work authorized by the team. A familiar display name does not establish that the invited identity is the one currently active.

After acceptance, confirm selected workspace and specific resource. Someone may use several environments with similar agents. Testing in the wrong workspace leads to misleading conclusions about the invitation. Record the resource and task that should work. Then review effective permissions in the interface and establish whether the action is included. Read access does not automatically imply editing or deletion.

Use a small reversible check to validate the permitted task. If the person only reviews activity, do not test deletion or tool modification merely to demonstrate access. Also check a relevant restriction that should remain. Validation should establish that authorized work is possible without turning an invitation correction into indiscriminate capability expansion. This sequence diagnoses blocked access through evidence rather than repeated role changes until the error disappears. Keep the outcome recorded so the same identity mismatch is easier to recognize if it recurs.

Check resource access and integration dependencies

Workspace access does not establish every permission over agents, tools, and documents. Someone may view a resource without editing or deleting it. Tigy offers access options and summaries that should guide configuration. Do not assume a fixed role matrix beyond what the interface and documentation provide for that installation. Verify the concrete action on the concrete resource.

In a fictional team, a person can edit instructions but cannot change a tool. Check whether their account can access that resource. If the tool connects to another system, ask the integration owner to check the connection’s authorization too. Never copy access keys into support requests or screenshots; describe the step and error message without exposing secrets.

Separate a person’s access to Tigy from a connection’s access to an external service. A tool may depend on an account or key managed by another team. Giving a colleague access to the agent does not automatically transfer those responsibilities. List the necessary connections and their owners to find the cause of a refusal.

After adjustment, repeat the authorized action and verify that relevant restrictions remain. If a credential changed, test the integration using suitable test information. Do not use a real request that writes or sends information merely to establish that a button works again. Validation should follow action impact and access purpose, showing the resource can be maintained without opening unnecessary capabilities. Record the result so future access changes can be reviewed against the same operational expectation rather than starting from assumptions about what the role ought to permit.

Plan access changes without interrupting operations

When someone changes roles or leaves a team, review access and dependencies before removing participation. Check who maintains integrations and the external-service credentials used by tools. An agent may continue answering questions but fail only when invoking a tool whose credential lost access. Review the complete service path rather than merely whether the agent remains present in the workspace.

In a fictional example, one colleague maintained calendar integration and another takes responsibility. Identify related credentials, permissions, and destinations. Transition maintenance through available options and team procedures, then test lookup and action with an appropriate scenario. Do not hand over the former owner's personal password as a continuity solution. Integration maintenance should follow an authorized organizational process. The new owner needs usable access to the resources involved, not just responsibility written in a document.

Distinguish member removal, account deletion, and workspace deletion. Ending participation does not require deleting shared space containing agents, tools, documents, and other people. Workspace deletion has broader scope and should be chosen only when that resource genuinely needs to end. Member and permission settings provide the documented route for reviewing team participation. Choose the action from the actual objective rather than using deletion as a general access reset.

Record changed access and work continuing under another owner. When removal affects an integration, confirm final state rather than assuming absence from the people list proves every dependency is resolved. Careful review preserves continuity without retaining unnecessary personal access. The desired outcome is a team knowing who can change each resource and who maintains it, with permissions aligned to current responsibility. Test the affected service after transition and retain its result as evidence that both access removal and operational continuity succeeded.

Use periodic reviews to check effective access

An access review can be short when it starts from known tasks and resources. Check who still performs each responsibility, which accounts remain active, and which permissions no longer serve a purpose. Temporary projects may leave forgotten access after completion. Service changes may create new work for someone previously reviewing only results. Update configuration from that operational reality.

When access changes, include a permitted-task check and a relevant restriction check. The interface shows configured access; practical verification shows whether it supports the job. If an action fails, investigate identity, invitation, workspace, resource, and dependencies before expanding a role. Rejection may represent a correct restriction or incorrect context, and correction depends on that distinction. Keep these checks proportionate to the task rather than testing broad capabilities the person does not need.

Coordinate permissions with account protection. Authentication helps establish who signs in; permissions determine what that identity can do. Two-factor activation does not eliminate resource-access review. Reducing a role does not replace careful handling of external credentials. These measures address different parts of operations and should remain coordinated, particularly for people able to alter instructions or write tools. The effective control comes from their combination rather than one setting alone.

Track changes causing interruption, access requiring temporary expansion, and accounts with unclear responsibilities. Use findings to improve the task matrix and maintenance transitions. The aim is not an extensive review for every edit, but explainable, verifiable access. Small teams also benefit from knowing why each person has a capability and how to remove or adjust it without losing service that must continue. A short ownership record and a concrete validation result provide a more durable basis than remembering which administrator last fixed an access error.