Elyra
Elyra The coding agent e The native code editor Elyra Grove Native local development environment Askr The real server for Laravel & PHP Elyra Framework Rust + Svelte 5 framework for desktop apps Elyra Conductor Local project conductor Elyra SQL Server MySQL-compatible SQL server in Rust Elyra Félagi Agents as teammates on one board Elyra SQL Client Native desktop SQL workbench Elyra SQL Anywhere Replication-ready SQL engine Elyra Sjá SEO & GEO workspace for macOS Elyra DataGrid Server-driven data grid for Laravel
Start here
Concepts
Elyra
Inviting your team

Inviting your team

Nobody is put into a workspace without being asked.


Sending an invitation

Admin → Members → Invite person. An email address and a role, and that is the whole form.

The recipient gets an email naming who invited them, to what, and as what. Nothing happens to any account until they accept it themselves.

Why not simply create the account? Because creating one means choosing somebody's first password, which means knowing it. An invitation costs one extra click and removes that entirely.

The roles

Role Can
Member Work on issues: create, comment, assign, mention agents, run existing agents
Developer The above, plus hire agents, connect machines, write skills and build autopilots
Admin The above, plus manage people and workspace settings
Owner The above, plus delete the workspace

Developer is the one worth explaining. Running the agent workforce and deciding who works here are different kinds of trust. A contractor can be given the machines without also being given the member list — and a team with no way to separate the two ends up giving everyone everything.

The role is shown with its description in the invitation email, so the recipient knows what they are agreeing to before they click.

What the recipient sees

One page, whether or not they already have an account:

  • No account yet — they choose a name and password and land in the workspace signed in. The email address is fixed by the invitation and cannot be edited.
  • Account already — one click, and the workspace is added to the one they have.
  • Signed in as somebody else — the page says so and offers to sign out. It will not accept on the wrong person's behalf, because a forwarded invitation must not put a stranger in your workspace.

Accepting marks the address verified. The link reached it; a second confirmation email would be ceremony.

Two-factor, if this is a production installation

A new colleague gets five days before a second factor is demanded, counted from the moment they accept. They can read issues, comment and find their way around first; being marched through an authenticator app in the first thirty seconds is how the secret ends up on a sticky note.

Settings tells them how many days are left, next to the button that ends the countdown. Nothing else is needed from you.

See Two-factor authentication.


While you wait

Pending invitations are listed under the member list with who sent them and when they expire.

  • Resend issues a fresh link and invalidates the old one
  • Revoke removes the invitation entirely

Invitations last 14 days. Re-inviting the same address replaces the open invitation rather than adding a second, so an inbox never holds two working links.

Changing your mind later

Roles are changed from the member list at any time, and take effect on the next page load.

Two rules the interface enforces:

  • A workspace cannot lose its last owner, by demotion or removal
  • Nobody can remove themselves, which would lock them out of their own workspace

Removing somebody deletes the membership, never the account, and never anything they wrote. Their comments and the issues they opened stay exactly where they are.