# User Management

Interlynk uses an invitation-based team management model. Users are invited to an organization by email, assigned a role, and gain access after accepting the invitation.

***

## Inviting Team Members

### Role Assignment at Invite Time

When inviting a user, you can optionally assign a role. If no role is specified, the user receives the default role configured for the organization. Roles determine what the user can view and modify — see [Role Management](https://docs.interlynk.io/administration/role-management) for the full permission matrix.

### Prerequisites

* You must have the `invite_users` permission (available to Admin and Operator roles by default).
* The invited user must have a valid email address.

### Step-by-Step: Invite a User

1. Navigate to **Settings > Organization > Users**.
2. Click **Add User**.
3. Enter the user's **Email** address.
4. Select a **Role** from the dropdown (Admin, Operator, Viewer, or any custom role).
5. Click **Invite**.

The user receives an email invitation with a link to accept.

### Email Verification Flow

1. The invited user receives an email with an invitation link containing a secure token.
2. The invitation token is valid for **24 hours**. After expiry, the invitation must be resent.
3. If the user already has an Interlynk account, they can accept the invitation and immediately access the organization.
4. If the user does not have an account, the invitation link directs them to complete registration before accepting.
5. Upon acceptance, the user's status changes from **Invited** to **Accepted**.

### Pending Invitations

Invitations that have not been accepted appear with a **Pending** status in the users table. You can:

* **Resend** the invitation if it expired or the user did not receive it.
* **Remove** the pending invitation to revoke access before acceptance.

***

## Changing Team Member Roles

### Permission Model Overview

Interlynk uses a role-based access control (RBAC) model. Each user in an organization is assigned exactly one role. Roles contain a set of permissions that govern access to features.

Role changes take effect immediately — the user's next API call or page load will reflect the new permissions.

### Who Can Change Roles

* **Admin** users can assign any role, including Admin.
* **Super admins** (platform-level) can update any role assignment.
* Non-admin users cannot change roles, even their own.

### Step-by-Step: Change a User's Role

1. Navigate to **Settings > Organization > Users**.
2. Locate the user in the table.
3. Click the action menu on the user's row.
4. Select **Change Role**.
5. Choose the new role from the dropdown.
6. Confirm the change.

### Audit Logging

Role changes are tracked in the platform's activity log. The log records:

* Who made the change
* The previous role
* The new role
* Timestamp of the change

***

## Removing Team Members

### Step-by-Step: Remove a User

1. Navigate to **Settings > Organization > Users**.
2. Locate the user in the table.
3. Click the action menu on the user's row.
4. Select **Remove**.
5. Confirm the removal.

{% hint style="info" %}
You cannot remove yourself from the organization.
{% endhint %}

### What Happens to Owned Assets

When a user is removed:

* The user loses access to the organization immediately.
* SBOMs, products, and other data created by the user remain in the organization — they are not deleted.
* API tokens (user tokens) associated with the removed user are no longer valid for the organization.
* Service tokens created by the user continue to function — they are bound to the organization and outlive their creator. Admins retain full visibility over these tokens and can revoke them if needed.

### Access Revocation Timing

Removal is a soft delete. The user's access is revoked immediately:

* Active sessions are invalidated.
* API tokens for the organization stop working.
* The user no longer appears in the organization's user list.

If the user is a member of other organizations, those memberships are unaffected.

### Offboarding Checklist

When a team member leaves your organization, follow this checklist:

* [ ] Remove the user from the organization in Interlynk.
* [ ] Review and revoke any **user tokens** created by the departing member.
* [ ] Audit **service tokens** — service tokens outlive their creator and continue to function. An admin should review the departing user's service tokens (visible to all admins) and revoke any that are no longer needed.
* [ ] If the user was an Admin, review recent activity logs for any configuration changes that should be audited.
* [ ] If SSO is enabled, remove the user from your identity provider as well to prevent re-authentication.
* [ ] Update any shared documentation that references the user's personal tokens or credentials.

***

## Common Misconfigurations

| Issue                                            | Symptom                                 | Fix                                                             |
| ------------------------------------------------ | --------------------------------------- | --------------------------------------------------------------- |
| Invitation expired                               | User clicks link and gets an error      | Resend the invitation from the Users page                       |
| Wrong role assigned                              | User can access features they shouldn't | Change the role immediately — takes effect on next request      |
| Removed user's service tokens still active       | Automated pipelines continue running    | Service tokens are org-bound — revoke them separately if needed |
| SSO user removed from Interlynk but not from IdP | User can re-authenticate via SSO        | Remove the user from your identity provider as well             |
| No admin remaining                               | Cannot manage organization              | Contact Interlynk support to restore admin access               |

***

## Recommended Best Practices

* Assign the **least privileged role** at invite time. Promote to higher roles only when needed.
* Use the **Viewer** role for stakeholders who need read-only access to dashboards and reports.
* **Audit your user list** quarterly — remove inactive users and verify role assignments.
* Prefer **SSO** for organizations with more than 10 users to centralize identity management.
* Use **service tokens** instead of personal tokens for shared automation to avoid dependency on individual team members.