Create your first repository

After you can sign in and open the right repository, build one real workspace. Do not create a demo tree that nobody will use.

A useful first repository answers three questions:

  • Where does this work live?
  • Who owns it?
  • Who can access it?

Before you start

Confirm these basics:

  • Explorer opens for the repository.
  • Search opens for the same repository.
  • You can create folders or files in at least one location.
  • You know whether the repository is for personal work, a team, a company, or external collaboration.

For most teams, begin with something simple:

  • Projects/ for active delivery work
  • Operations/ for recurring internal work
  • Shared/ for cross-team collaboration

Keep depth shallow. Clear names beat clever taxonomies. Avoid root folders named after tools, such as Emails, Tasks, or Chats, unless they are real business areas. SynckHub already provides focused views for those content types.

Step 1: Open the real folder before creating work

Use Explorer to open the folder that should own the work. If the work belongs to a customer, case, project, or department, create it there.

Do not create long-lived work from a recent-content view unless you know where the item will land.

Step 2: Seed one collaboration loop

Inside one real project or work folder, create:

  1. a file for the main working document
  2. a note for durable context
  3. a task for ownership and execution
  4. a chat thread for discussion

If your deployment has connected mail or calendar, test one realistic adjacent action too:

  • save an email or attachment into the same folder
  • create a meeting note from a calendar event
  • link a decision back to the same project, company, contact, or case context

Step 3: Check focused views

Focused Explorer views help users move faster:

  • Files shows file work.
  • Notes shows text-first context.
  • Tasks shows execution.
  • Chats shows discussion.
  • Companies, Contacts, and Cases show structured relationship/work records when enabled.

Open at least one item from a focused view, then confirm users can still reach the owning folder. If they cannot tell where the work lives, your setup is not ready.

Step 4: Invite only the first collaborators

Start with the smallest useful group:

  • owners who maintain the folder structure
  • contributors who need to edit
  • reviewers who only need read access

Avoid broad root access during setup. It is easier to expand access than to clean up accidental exposure later.

Verification

You should be able to confirm all of this:

  • the Explorer route loads and shows root folder content
  • Search returns results inside the selected repository
  • a teammate can open the intended project folder
  • history or activity is visible after an edit
  • focused views do not hide the owning folder context
  • access behaves as expected for one owner, one contributor, and one viewer

If any of that fails, fix it before broader rollout.

Next steps

Previous
Core Concepts
Next
Directory