Set Up Companies, Staff, and Sub-groups

Companies and sub-groups organize workers for permissions, reporting, rates, availability, and dispatch. Build the structure first, then place each user in the correct group.

What you will accomplish

By the end of this guide, you will be able to complete the staff organization structure from the correct CleanOver screen, understand the important checks before saving, and verify that the result is visible to the people who use it next.

Before you begin

• List the legal or operational companies and the teams beneath them.
• Decide who manages each group and which modules each role needs.
• Sign in to the Admin workspace and confirm you are in the correct business context.
• Use real operational dates and the property’s local timezone when the workflow includes time.

Step 1: Open Users

Go to Team Management > Users and review the current company and group hierarchy. Search for the company before creating it.

Expected result: You avoid duplicate organizations.

Step 2: Create the company or group

Use a clear operational name and add the appropriate contact and configuration details.

Expected result: The company is recognizable in assignment and reporting screens.

Step 3: Create useful sub-groups

Add sub-groups for real dispatch or management boundaries, such as region or specialty. Avoid groups that no workflow will use.

Expected result: The hierarchy matches how work is assigned.

Step 4: Add the staff user

Create a unique user with the person’s correct name and sign-in contact. Assign the company, subgroup, manager, and role.

Expected result: The person belongs to the intended reporting line.

Step 5: Set permissions

Grant the minimum module and action access needed for the role. Review sensitive financial, settings, and API permissions separately.

Expected result: The worker can do their job without unnecessary access.

Step 6: Configure operational eligibility

Set job types, tags, deep-clean authorization, or other specialty controls used by dispatch.

Expected result: The worker appears as an eligible choice only where appropriate.

Step 7: Add availability and rates

Complete Resource Planning and the applicable cleaner rate configuration before assigning normal work.

Expected result: The worker can be scheduled and paid correctly.

Step 8: Test and review

Sign in or verify the worker view, assign a test job, and schedule a periodic access review.

Expected result: The organization, visibility, and assignment behavior are correct.

How to confirm the workflow is complete

• Refresh the destination list or calendar and confirm the saved record appears only once.
• Check the unit, date, status, owner or assignee, and any linked record before leaving the page.
• Open the next downstream view mentioned in the guide and confirm it shows the same information.
• Record an internal note when the action corrects historical data or changes another person’s responsibility.

Common issues and what to do

The expected record is missing

Clear old filters, check the date and business context, then search by the most specific identifier available. If the data comes from a connected provider, check connection and mapping status before recreating it manually.

A button is disabled

Look for a required field, incomplete checklist item, missing permission, locked lifecycle status, or unresolved linked task. Complete the highlighted requirement instead of trying to bypass it.

The page shows different information after refresh

Another user or integration may have updated the record. Compare timestamps and the source system, then apply the correction in the system that owns the data.

You are unsure whether to continue

Stop before cancelling, overwriting, revoking, or issuing a financial document. Ask the workflow owner to confirm the intended outcome and add that decision to the internal record.

Best practices

• Use clear names that make sense to a new team member without extra context.
• Prefer the smallest safe scope for bulk actions, filters, permissions, and date ranges.
• Keep guest-facing communication separate from internal diagnostic notes.
• Verify a high-risk change in a second view before considering it finished.
• Update the source configuration when the same correction is needed repeatedly.