Invite your first team member

How to invite a team member to your SGEN site

Adding a team member to your SGEN site takes about two minutes once you know what role to give them. This guide walks through the entire flow — from the invite form to the moment you confirm that the new user can do their job.

Every user in SGEN is tied to a role. The role determines which sections of the dashboard they can see, which actions they can take, and what they cannot touch. An Editor can write and update content but cannot change site settings. An Admin can configure everything. You decide which role each person gets when you send the invite — and you can change it later.

The invite is email-based. SGEN sends a message to the address you specify. The recipient clicks the link, sets their password (or logs in with an existing account if they have one), and lands directly in the sections their role allows. From that point on, they are an active member of your site's team.

By the end of this guide, your team member will have received their invitation, logged in, and confirmed access to the sections their role covers. You will also know how to monitor their activity through the audit log and how to remove their access if the arrangement changes.

What is this for?

This guide covers the Users section of SGEN Settings — specifically the invite flow that gives another person access to your site's dashboard.

Use this when you need a real person to log in and do work inside your SGEN admin — writing content, managing orders, configuring settings, or reviewing submissions. The invite creates a named account tied to their email address. Every action they take in the dashboard is recorded against their account in the audit log.

This is one of the first things most teams do after their site goes live. A common pattern: start with a single Admin account for the founder, invite a Marketing Manager on day one, and end the first week with four users across three roles — a pattern that fits most small teams.

You do not need a developer to complete this. There is no code, no API, and no configuration outside the Settings panel. If you can log in to the dashboard, you can invite someone.

Good use cases

These are the situations where this guide applies.

• Bringing on a marketing manager. A founder invites

their new marketing manager on day one. The marketing manager needs to write blog posts, update pages, and manage the events calendar — but should not be changing payment settings or touching integrations. An Editor role is the right fit. The founder sends the invite, the marketing manager accepts, and within minutes they are writing their first post.

• Contracting an editor or freelancer. You commission

a freelance writer to produce four monthly articles. The writer needs to draft and submit posts — nothing else. An Author or Contributor role gives them a scoped workspace without access to anything sensitive. When the contract ends, the account is removed.

• Handing admin access to an agency partner. Your web

agency handles technical maintenance and occasional template work. They need full Admin access to make configuration changes. Invite the agency's point of contact as an Admin, with the understanding that the account is reviewed quarterly. The audit log shows everything the agency account touches.

• Onboarding a new support staff member. A new hire joins

your customer support team. They need to manage form submissions and view customer inquiry threads. A Contributor role covers that scope without giving them access to content publishing or site settings.

• Adding a co-founder or business partner. A second

owner joins the operation. They need the same level of access as the first. An Admin invite gives them full dashboard access from day one.

• Inviting a finance lead who only needs order data.

Your bookkeeper needs read access to order history and invoice records. A scoped role (Contributor or a custom configuration) lets them see what they need without touching anything else.

What NOT to use this for

Invitations are for named team members who need to log in and take action in your dashboard. There are several things that look similar but require a different approach.

• Anonymous public commenting. If you want visitors to

leave comments on your blog posts, that is handled by your comment settings — not by user accounts. Public commenters do not log in to the dashboard. They interact on the public side of the site.

• Customer accounts on the public site. If you run

an e-commerce store and want customers to create accounts to track orders or save preferences, those are storefront accounts — not dashboard users. Customer-facing account management lives in a different area of SGEN. Sending a dashboard invite to a customer would give them access to your admin, which is not what you want.

• Single sign-on with an external identity provider.

If your organization uses an external SSO system — Google Workspace, Microsoft Entra, Okta, or similar — and you want your team to log in through that system rather than with SGEN-native credentials, that is an SSO integration, not an invite flow. Contact your SGEN support team or check the SSO configuration guide. The invite flow described in this guide creates SGEN-native accounts.

• Giving someone view-only access to a specific page.

There is no "view this one page" permission. User access in SGEN is role-based across the dashboard. If someone only needs to see a report or review a piece of content, consider exporting the content rather than creating an account.

• Temporary read-only audit access for a compliance review.

If a third party needs to verify your site's content or configuration for a compliance purpose, discuss with your SGEN administrator whether creating a temporary scoped account is the right approach, or whether an export or screenshot-based review is more appropriate.

How this connects to other features

The Users section connects to several other areas of SGEN. Understanding those connections makes the invite decision cleaner.

• Roles and permissions. Every user is assigned a role

at the time of invite. The role determines what they see and what they can do. The four built-in roles are Admin, Editor, Author, and Contributor. A full breakdown of what each role covers is in the Roles and Permissions reference. Read that before you send the first invite — it takes three minutes and prevents the common mistake of assigning too much access too early.

• The notification email. When you send an invite, SGEN

sends an automated email to the recipient with a link to set their password and log in. The email comes from your site's configured notification address. If your invitee does not receive the email, check your notification settings and your site's outgoing mail configuration.

• The audit log. Every action taken by every user in

your dashboard is recorded in the audit log — which page was created, which setting was changed, which post was published, and who did it. Once your team has more than one user, the audit log is how you know what happened and who is responsible. Enable it before you add anyone to your team.

• Two-factor authentication. Admin and Editor accounts

may prompt the user for 2FA setup on first login, depending on your security settings. If 2FA is required and the new user is not expecting the prompt, they may think something is broken. Let new users know to expect it.

Before you start

A two-minute check before opening the invite form saves a round-trip later.

Decide on the role. This is the most important decision in the entire process. Assign the minimum role that lets the person do their job. If they need to write and publish content independently, Editor is right. If they only submit drafts for someone else to approve, Author or Contributor is the better fit. If they need to configure settings, change integrations, or manage other users, they need Admin. When in doubt, start with a lower role and promote later — it is easier to grant more access than to walk back an over-privileged account.

Have their email address ready. SGEN sends the invite to the address you enter. Use the address your team member checks regularly. If they have separate work and personal addresses, confirm which one they want to use for site access.

Know what welcome message to send. The invite form has an optional message field. A one-line note — "I've added you as an Editor on our SGEN site so you can start publishing the event posts. Let me know if you have questions." — goes a long way toward making the first login smooth, especially for people who have not used SGEN before.

Confirm the audit log is enabled. Before adding any user other than yourself, check that the audit log is turned on in Settings. You want a record of activity from the moment the first team account becomes active — not from later when something has gone wrong.

Where to go

Go to Settings in the left sidebar of your SGEN admin dashboard. Under the Users section, click Users. The Users list shows all current accounts and their statuses. Click the Invite User button at the top right.

The invite form opens as a panel or modal. It has four fields: email address, role selection, an optional welcome message, and a send button. All the steps below happen inside this form.

Navigation path: the admin → Settings → Users → Invite User

Steps — Invite your first team member

These steps take you from a blank invite form to a confirmed, active team member with the right level of access.

1. Open the invite form

Go to the admin → Settings → Users. Click Invite User at the top right of the Users list. The invite form opens.

If you do not see the Invite User button, check your own role. Only Admins can invite new users. If you are logged in as an Editor, you do not have access to user management — you will need to ask an Admin on your site to send the invite.

2. Enter their email address

In the Email address field, type the recipient's email address. Double-check it before moving on. SGEN sends the invite to exactly the address you enter. A typo here means the email goes to the wrong address or nowhere — and the invitee will wonder why they never received anything.

Enter Jordan's email address — the same address they use for all internal communications.

3. Select their role

In the Role dropdown, select the role that matches what they will be doing on the site.

For Jordan Kim, who will be submitting draft content for review but not publishing independently, Contributor is the correct choice. For Marcus Webb, who publishes and updates content on his own, Editor is right. For the agency partner who needs to touch configuration settings, Admin is the call.

If you are not sure, choose the lower role and promote after they have logged in and confirmed what they need. Changing a role takes ten seconds. Cleaning up after an over-privileged account takes longer.

4. Write a welcome message (recommended)

The optional welcome message field adds a personal note to the invite email. You do not have to fill it in, but it is worth the thirty seconds.

Keep it functional: what site they are being added to, what role they have, and who to ask if something is not working. A good welcome message: "Hi Jordan — I've added you as a Contributor on our SGEN site. You'll be able to submit draft posts for review once you accept the invite. Ping me if anything looks off on first login."

That is enough. The invite email already contains the login link, the site name, and instructions for accepting. The message is context, not documentation.

5. Send the invite

Click Send Invite. SGEN sends the invite email immediately and adds the recipient to your Users list with a Pending status. The Pending status stays until they accept.

If the email is not delivered within a few minutes, check the Troubleshooting section at the bottom of this guide.

6. They accept and log in

The invitee receives an email with a subject line from your site and a link to accept the invitation. They click the link, set their password (or log in if they already have a SGEN account), and land in the dashboard sections their role allows.

Their status in your Users list changes from Pending to Active as soon as they complete login. You will see the change reflected in the Users list the next time you load it.

If 2FA is enabled on your site for their role, they will be prompted to set up two-factor authentication during this first login. Let them know to expect it so they are not surprised.

7. Verify they can do their job

Log out of your own session (or open a second browser) and ask your new team member to walk through their first task. Alternatively, check the sections yourself with their permissions in mind.

An Editor should be able to: navigate to Blog, open the post editor, write a post, and publish it. They should not see the Settings menu (or should see it in a restricted state). If they can publish a post and cannot access Settings, the role is correct.

A Contributor should see the Blog area and be able to submit a draft, but should not be able to publish independently. If the Publish button is replaced by a Submit for Review button, the role is working as intended.

If access looks wrong, go back to Users, open their account, and check the assigned role. Adjust if needed — it takes one click.

8. Enable the audit log for visibility

Go to the admin → Settings → Audit Log and confirm it is enabled. If it was not enabled before you sent the invite, enable it now. From this point forward, every action taken by every user — including your new team member — is recorded with a timestamp, user name, and description of what changed.

The audit log is not about distrust. It is the record that lets you reconstruct what happened if a post disappears, a setting changes unexpectedly, or content goes live that was not supposed to. With more than one user on the site, the audit log is the only way to know what happened and who did it.

What success looks like

When the invite process is complete and the new user is set up correctly, these things are true.

• The user appears in your Users list with an Active status.
• Their assigned role is correct — confirm by opening their

profile in the Users list and checking the Role field.

• They can navigate to and interact with the sections their

role covers. An Editor can open the post editor and publish. A Contributor sees the draft submission workflow, not the Publish button.

• They cannot access areas outside their role. An Editor

should not be able to modify Settings. A Contributor should not be able to publish content without review.

• The audit log shows their first login event and any actions

they have taken since accepting.

• The invite email is no longer in a Pending state — the

Users list shows Active, not Pending.

If all six of those are true, the invite is done and the access is correctly scoped.

What to do if it does not work

The invite email was not received. Check the email address entered in the invite form — open the user's entry in the Users list and confirm the address is correct. If it is correct, check your site's outgoing mail settings in Settings → Notifications. If outgoing mail is not configured or the notification email address is missing, the invite email has nowhere to come from. Some mail providers also filter automated emails to a spam or promotions folder — ask the invitee to check there.

The invite link has expired. Invite links expire after a fixed period (typically 48-72 hours depending on your site configuration). If the invitee clicks the link after it has expired, they will see an error. Go to your Users list, find the Pending entry for that user, and select Resend Invite. A fresh link is sent immediately.

They accepted but the wrong role was assigned. Go to Settings → Users, open the user's profile, and change the role using the Role dropdown. Save. The role change takes effect on their next page load — they do not need to log out and back in for most role changes. If they are currently logged in, ask them to refresh their browser.

They cannot see a section they expect to have access to. Confirm their role covers the section in question. Check the Roles and Permissions reference to verify the role's scope. If the role is correct and the section is still not appearing, check whether the section is enabled for your site plan — some features are plan-gated. Contact your SGEN support team if the expected section is part of your plan and is not visible.

They are prompted for 2FA but were not expecting it. This is expected behavior if 2FA is required for their role. Let them know this is intentional — it is a one-time setup that takes two minutes. They need their phone and an authenticator app (Google Authenticator, Authy, or equivalent). Once set up, 2FA is a normal part of their login flow.

Removing access when someone leaves the team. Go to Settings → Users, find the user's entry, and select Remove User or Deactivate. Their account is immediately disabled — they can no longer log in. Any content they created is preserved under their name in the dashboard. If you want to transfer ownership of their content to another user, do that before deactivating the account. The audit log retains their activity history even after the account is removed.

Tips for managing team access well

A few habits that prevent the common access problems as your team grows.

• Start with a lower role and promote when they ask for more.

The most common mistake on small teams is inviting everyone as Admin because it is easier than thinking through the role. That works until something changes — a contractor finishes their engagement, a team member changes roles, an account is compromised. Scoped access is easier to audit and easier to revoke cleanly.

• Review your Users list quarterly.

Go to Settings → Users every three months and confirm that every Active account still belongs to someone actively working on the site. Deactivate accounts that are no longer needed. This is the difference between a manageable team list and a roster full of accounts you are no longer sure about.

• Use the welcome message to set expectations.

A two-sentence message in the invite email prevents the "I don't know what I'm looking at" first-login experience. Tell them which sections they have access to and who to contact if something is confusing.

• Keep the audit log on from day one.

The audit log is most useful when it has complete history from the beginning. Turning it on after something has gone wrong means you are missing the context that would tell you what happened. Enable it before your team grows.

• Do not share Admin credentials instead of inviting.

Sharing a password means the audit log cannot distinguish between users, you cannot remove one person's access without changing the credentials for everyone, and your site's security posture depends on everyone involved keeping the password safe. Invite each person individually.