How to onboard new team members and assign user permissions in Mylighthouse

Getting a new teammate set up in your tools should be quick, painless, and as foolproof as possible. But let’s be honest—user management screens can be a headache, and it’s way too easy to overthink permission settings or miss something important. If you’re using Mylighthouse and want a no-nonsense walkthrough for onboarding new folks and getting their permissions right, you’re in the right place.

Whether you’re a team lead, admin, or just the unlucky one stuck with the “add everyone to the new system” job, this guide is for you. I’ll walk you through what actually matters, what to skip, and how to avoid the common mistakes. Let’s get to it.

Step 1: Know What You’re Setting Up (and Why)

Before you start clicking, take a minute to figure out:

  • What does this person actually need to do in Mylighthouse?
    • Are they running projects, tracking issues, just peeking at reports?
  • Who really needs admin rights?
    • Spoiler: It’s probably not everyone.
  • What’s the worst that can happen if someone has too much access?
    • It’s easier to loosen permissions later than to undo a mess.

Pro Tip

Don’t just copy-paste roles from your last tool. Mylighthouse has its own quirks—get familiar with what each role really means.

Step 2: Add a New Team Member

Assuming you have admin rights (if not, ask someone who does), here’s how to get someone new into Mylighthouse:

  1. Log in and go to Settings.
  2. Look for a “Team” or “Users” tab. If you don’t see it, you’re probably not an admin.
  3. Click “Invite User” or “Add Member.”
  4. You’ll need their email. Double-check it—typos slow everything down.
  5. Pick a role or permission level.
  6. See the next step for what actually matters here.
  7. (Optional) Send a custom message.
  8. Not necessary, but a quick “Welcome!” or “Here’s what to do next” never hurts.
  9. Send the invite.
  10. They’ll get an email. If it’s not in their inbox, tell them to check spam. (Yes, really.)

What Works

  • Inviting in batches if you have a lot of people—just copy-paste a list of emails.
  • Sending a heads-up Slack/Teams message so folks know to expect the invite.

What Doesn’t

  • Over-explaining what Mylighthouse does in the invite. Keep it short; people ignore long emails.
  • Waiting days between invitations and follow-ups—get people in while it’s fresh.

Step 3: Assign User Permissions (Don’t Overthink It)

Mylighthouse has a few standard permission levels. They usually go something like:

  • Admin: Full access to settings, billing, adding/removing users, everything.
  • Manager/Editor: Can create and manage projects, but can’t nuke the whole account.
  • Viewer/Read-only: Can see stuff, but not change things.

How to Assign Permissions

  1. During the invite: Pick the role from a dropdown. If you’re unsure, start with less access.
  2. After the user accepts: You can always change their role later from the Team/Users screen.

Honest Take

  • Most people should not be Admins. Only give admin to people you trust not to break things (or rack up charges).
  • If you’re not sure, use Editor/Manager. It’s enough for most day-to-day work, but not dangerous.
  • Viewer is for clients, auditors, or new folks shadowing the team. Don’t use it for people who need to actually do work.

What to Ignore

  • Granular, feature-by-feature permissions (unless you’re in a highly regulated industry). You’ll waste time micromanaging. Stick with the main roles unless there’s a real reason.
  • Old, inactive accounts. Clean these out once a quarter. No need to drag them through onboarding again.

Step 4: Set Up Teams or Groups (If You Need Them)

If you’re running a small shop, this might be overkill. But if you have a bunch of people, grouping them can make life easier.

  • Create teams by department, project, or role.
    • Example: “Designers,” “QA,” “Managers.”
  • Assign team-level permissions.
    • This way, when someone joins “QA,” they get all the right access in one go.
  • Use teams for bulk changes.
    • Need to lock down a feature for everyone in “Finance”? Do it once, not twenty times.

Don’t Go Overboard

  • Start simple. You can always add more teams or tweak later.
  • Avoid “just in case” teams—they’ll confuse everyone.

Step 5: Onboarding Checklist for New Members

Getting people into Mylighthouse is only half the job. They also need to know what to do next.

Here’s a bare-bones checklist to hand off (or include in your welcome message):

  • [ ] Accept the invite and set up your profile (photo, name, etc.)
  • [ ] Review your dashboard—see what’s available
  • [ ] Check out the “Help” or “Getting Started” guide (if Mylighthouse has one)
  • [ ] Join the right teams/groups (ask your manager if you’re not sure)
  • [ ] Try creating or editing a test item/project (if you have permissions)
  • [ ] Ask questions early—don’t guess

Pro Tip

  • Pair new folks with a “buddy” who’s used the tool before. Saves everyone time, and they’ll get unstuck faster.

Step 6: Review and Adjust Permissions Regularly

Permissions aren’t “set it and forget it.” People change roles, leave, or need more/less access.

  • Once a quarter, review the user list.
    • Remove or downgrade anyone who’s left or changed jobs.
  • Spot-check admins.
    • Too many admins is a security risk.
  • Listen for complaints.
    • If people are blocked from doing their work, loosen things up. If someone’s breaking stuff, tighten it down.

What’s Not Worth Your Time

  • Panicking over one-off mistakes. If you accidentally gave someone too much access for a week, fix it and move on.
  • Trying to predict every edge case. Set good defaults, and adjust as you go.

Step 7: Handle Problems Quickly

Mistakes happen. Someone gets the wrong access, or can’t see what they need.

  • Fix permissions right away. Don’t let people sit blocked for days.
  • Communicate clearly. A quick “Hey, I updated your access” goes a long way.
  • Log out and back in. If someone says “it still doesn’t work,” have them refresh or log out—90% of the time, this fixes it.

Common Pitfalls (and How to Dodge Them)

  • Too many admins: Only the folks who really need it should have the keys to the kingdom.
  • Relying on memory: Keep a quick doc or checklist for onboarding steps, especially if you’re the “IT person by default.”
  • Ignoring offboarding: Remove access as soon as someone leaves. Lingering accounts are a security risk.
  • Complicated permission schemes: Simple is safer and easier to manage.

Wrapping Up: Don’t Make It Harder Than It Is

Getting new team members into Mylighthouse and setting their permissions doesn’t need to be a big project. Start with the basics, don’t get lost in the weeds, and remember: it’s easier to fix things as you go than to build a perfect system up front.

Keep it simple, check in now and then, and don’t be afraid to adjust if something’s not working. The less time you spend stuck in user management, the more time your team can actually get stuff done.