Skip to main content
Updated May 8, 2026 The most-seen issues with Team & Projects on Raff and the fix for each. If your issue isn’t here, contact support@rafftechnologies.com with the affected member’s email or API key prefix, the exact error message, and what you’ve already tried.

​
Invitations

First, check the dashboard:
  • Members tab → look for the row with the invited email. Its status should be Pending (gray badge). If the row is missing, the invite wasn’t actually sent — re-send via Invite a member
  • If the row exists, the email left Raff’s side. The likely problem is delivery
Common delivery issues:
  • Spam / junk folder — search for support@rafftechnologies.com or noreply@rafftechnologies.com in the recipient’s mailbox
  • Corporate email filter blocking unknown senders — recipient’s IT may need to allowlist rafftechnologies.com
  • Typo in the email address — Members row shows what was actually sent. Cancel the invite and re-send with the correct email
  • Disposable / role-based addresses (e.g. info@, noreply@) — some mail servers reject these silently
Reinvite the member: there’s no in-place “resend” action. The workflow is cancel + re-invite:
  1. Members tab → Pending row’s ⋮ → Cancel Invitation — the old email’s link stops working
  2. Click + Invite Member, enter the same email, send again — fresh token, fresh email
This is the reinvite pattern. It’s the same flow when fixing a typo’d email or changing the invite scope (Account vs Project).
No problem — accepting the invitation adds your account to their existing account list. They don’t create a new account, don’t pick a new password; they just see your account in the account-switcher dropdown after sign-in.They may need to sign in first (with their existing Raff credentials) and then click the invitation link, depending on the order of clicks.
Yes. Members tab → Pending row’s ⋮ → Cancel Invitation. The link in the email stops working immediately. The row disappears from Members.Cancelling and re-inviting is the right pattern when you need to change the invite scope (Account vs Project) — the Invite dialog locks the scope choice once sent, so a fresh invite is the way to switch.

​
Permission denied

Likely cause: they have an account role (so they can sign in and see account-level settings) but no project role on any project — so resources are invisible to them.The Account vs Project domains are independent on Raff. An Admin account role doesn’t grant access to project resources; only project roles do. See Roles, scopes, and the Owner for the model.Fix: open the member’s row, expand it, click + Add to Project, pick the project they should access, pick the project role. They see resources on next page load.
The member has a role, but the role doesn’t include the specific permission for that action.Diagnose:
  • Find the member on the Members tab → expand their row → see their account role and per-project roles
  • Open the Roles tab → click the eye icon on whichever role is being checked → look for the missing permission in the role-detail view
  • The permission name follows <domain>.<resource>.<action> (e.g. vm.delete, account.billing.manage)
Fix options:
  • Promote them to a role that does include the permission (e.g. Project Admin for full project access)
  • Build a Custom role with the exact permission set you want and assign that
  • For account-level permissions: change the account role; for project-level: change the role on that specific project
Most “missing permission” issues are confusion between domains — see Permissions matrix for which role grants which permission.
Role changes apply on the next API request the member makes. If they have a page open, they may continue to see stale state until they navigate or the page refreshes.Fix: ask the member to refresh the dashboard (Cmd-R / Ctrl-R) or sign out and back in. Their browser session state will reflect the new role.If a member is being demoted, they immediately lose access to anything the new role doesn’t include — open requests fail with 403. There’s no grace period.
Three common causes:
  1. The role assigned to the key was edited — adding or removing a permission on the role propagates to every key using it
  2. The role assigned to the key was deleted — keys whose role was deleted fail closed
  3. The key was rotated or deleted — the old value stops authenticating immediately
Diagnose: go to the API Keys page, find the key by its prefix (raff_<first 8 chars> is shown). Confirm:
  • Is the key still listed? If not, it was deleted
  • Has its Last Used field updated recently? If not, it’s not authenticating
  • What’s the role assignment? Is the role still valid?
Fix: rotate the key (Regenerate) to mint a new value, or recreate with the right role. See Rotate an API key.

​
Owner and last-admin scenarios

Only one Owner per account, and the Owner can’t be removed via the dashboard.Fix: contact support@rafftechnologies.com with:
  • Proof of authorization to make this change (often the Owner’s signed letter to the support team or board minutes for organizational accounts)
  • The new Owner’s email (already a member of the account, ideally with Admin account role)
Support transfers the Owner badge after verification. The previous Owner can then be removed normally.
The platform refuses to leave the account stranded with no one able to manage members.Fix: grant account.members.manage to at least one other member first:
  • Via a System role (Admin includes it)
  • Or via a Custom account role with that permission enabled
Then retry the original removal. The account always has at least one member-manager.
Same rule as above — grant the permission to someone else first, then they remove you. If there’s no one else suitable, contact support to coordinate the handoff (e.g. transfer Owner to a new hire, or close the account if shutting down).
No — exactly one Owner per account. The closest equivalent is two members with the Admin account role (Admin has 15 permissions vs Owner’s full 21, and excludes account.projects.delete and a few destructive ops). For most teams, two Admin members provide redundancy without an Owner conflict.

​
API keys after a member leaves

Expected behavior, not a bug. API keys carry their own role assignment — removing the member who created the key does not invalidate the key.Fix as part of offboarding:
  • Open the API Keys page
  • Filter / sort by Created By to find keys owned by the departed member
  • Rotate keys you want to keep (mints a new value, invalidates the old)
  • Delete keys that are no longer needed
Build this into your offboarding runbook. See Remove a member for the full checklist.
Rotation invalidates the old value the moment you confirm. If something is still trying it, the old value is hardcoded or cached somewhere.Diagnose:
  • Search code repositories for the old prefix (raff_<first 8>) — most leaks are committed values
  • Check secret-manager entries — was the rotation propagated to every system that uses the key?
  • Check logs for 401 Unauthorized from the old key — those are the systems still using it
Fix: update every system to use the new value. The audit log records who rotated when; you don’t need to change the key again, just deploy the new secret.
Raff stores only a hash of the key — the full value is unrecoverable after you close the create dialog.Fix: rotate the key (Regenerate) — issues a new value with the same role/expiration. Copy this one immediately to your secret manager. The old (lost) value is invalidated by the rotation.

​
Roles and Custom-role pitfalls

Two scopes for roles — Account and Project. Custom roles only appear in the dropdown that matches their scope:
  • Account-scoped Custom role → only in the Account Role dropdown
  • Project-scoped Custom role → only in the Project Role dropdown
Fix: confirm the scope you picked at create time matches where you’re trying to use the role. If wrong, delete the role and recreate with the correct scope — scope is locked after creation.
System roles cannot be edited. The toggles render in the role-detail view but submitting changes is blocked.Fix: click the row’s ⋮ → Duplicate to clone the System role into a Custom role. Edit the Custom role freely. Reassign affected members from the System role to the Custom one.
Roles can be deleted while audit-log entries reference them. Audit-log readability is degraded after the role is gone (the entry says the action was authorized by role-id <UUID> but can’t resolve to a name).Fix: there’s no recovery for deleted Custom roles. Recreate with the same name + same permissions if you need future audit-log entries to match. Old entries will continue showing the old role-id with no name.

​
Projects

Project visibility is governed by your project roles. The project picker in the top bar only shows projects you have a role on.Fix:
  • If you’re the Owner or have an account role with account.projects.view — open Team & Projects → Projects tab to see every project regardless of project-role grants
  • If you’re a Project-only member — you only see projects on which you have a project role. Ask an account-role holder to add you to the project you need
The Default project cannot be deleted, ever. It’s the always-available fallback project for any resource created without an explicit project. The Delete option is hidden / disabled on its row.See Edit or delete a project for the full rule and workarounds.
Not supported today. Resources are scoped to their project at creation, and there’s no “move resource” action.Workarounds:
  • Recreate the resource in the target project (snapshot + restore for VMs, copy-bucket for Object Storage)
  • For VMs specifically: take a snapshot in the source project, restore the snapshot in the target project, then delete the source VM

​
Still stuck?

Email support@rafftechnologies.com with:
  • The affected member’s email or the API key prefix (raff_<first 8 chars> — never include the full key)
  • The exact error message and the time it occurred
  • What you tried from this page
  • Whether this is a security incident (a leaked key, an unrecognized member sign-in, etc.) — these get prioritized
Same-day response in business hours; faster for production-impacting issues.

Roles, scopes, and the Owner

The model behind the permission errors above.

Permissions matrix

Which role grants which permission.

Rotate an API key

The most common offboarding action.
Last modified on May 11, 2026