How to Set Up Workspaces and Projects

Setup has an order. Create the workspace, put the right people in it, create a project, add a few sections, and set a short status list. Then add real tasks. Permissions, guest shares, and a second workspace are later decisions. Doing them on an empty project produces a structure nobody has tested.

This is the first-run sequence. It is not the argument for when a growing company needs more than one workspace. It is also not a tour of every role flag.

1. Create one workspace

A workspace is the boundary around a set of projects and the members who can open them. For a first setup, one workspace is enough if the people you are about to invite may see the projects you are about to create. Name it after the team or the company function, in words those people already use. "Marketing" is better than "Workspace 1."

Do not create a workspace per project. The project is the next step. A workspace with one project is normal. A workspace that exists only because a dialog asked for a name, and that you will never open again, is clutter.

You need permission to create a workspace. In a new organization that is the person setting Dayzen up. If you are not that person, ask them to create it and to give you membership, rather than inventing a side structure.

2. Add people before you add work

Invite the people who will own tasks in the first project. Give them a role that can do the work you expect in week one: see tasks, create tasks, and edit the tasks they are responsible for. You can narrow that later. An empty, perfectly locked workspace teaches nothing.

Do not invite the whole company "so they can have a look." Every member is someone who might see the projects in that workspace, subject to the role. Guests and limited shares are a separate setup. Leave clients out until there is a project worth showing.

People who only need HR records do not need a project membership. The login can be the same organization. The workspace is not automatic just because they are employees.

3. Create one project

A project is one outcome: a site launch, a campaign, an internal tool. Create that project inside the workspace. Name the outcome, not the year and not the tool. "Spring catalogue" beats "Projects."

If you have three outcomes, you may create three projects. Do not create them until the first one has tasks, or you will copy a blank pattern three times. One live project is the template you actually trust.

The project is not a folder on a personal to-do list. Tasks you add here are shared with members who can view them.

4. Add sections, then statuses

Sections are the areas inside the project. Two to four names are enough. How to choose them is covered in how to organize a project into sections. Do this before you import a long task list, so each task has a home.

Then set statuses. Map each visible name to Not started, In progress, Done, or Closed. Keep the list short. How to set up task statuses is the detail. A status template is worth saving only after this list has survived real tasks. On day one, type the names on the project and move on.

5. Add a handful of tasks

Create the tasks people will touch this week. Each one gets a section, an assignee, and a due date if a day is real. Leave estimates and dependencies until a task needs them. A project with forty empty cards and no owners is a spreadsheet with extra steps.

Open the board and the list. Confirm the same tasks appear. If a teammate cannot see them, fix membership before you build anything else.

What to postpone

• A second workspace. Add it when a group must not see this project's tasks, not because the menu allows it.
• Custom roles. The default role that matches week-one work is enough until someone has too much access or too little.
• Guest shares. Invite an outside person when there is something specific to show.
• Cycles, tags, and custom fields. They are useful later. They are not required for a task to exist.
• Charts. The Gantt is empty of meaning until dates exist. Add dates on the tasks that have them, then open the chart.

Postponing is the point of a first setup. You can add each of those without recreating the workspace.

A morning that finishes setup

Hour one: workspace and the four people who will work in it. Hour two: one project, three sections, five statuses. Hour three: ten tasks with owners. Stop. The afternoon is for doing a task, not for configuring a role. If the afternoon is still configuration, the setup was too wide.

Write down who can invite the next person. If that is unclear, the workspace will grow by whoever finds the button. That is the only governance a first week needs.

The first task, checked by someone else

Setup is finished when a second person can complete a loop without you. Ask them to create a task in the right section, set it to In progress, assign it to you, and put a due date on this week. You should see it on the board and on the calendar. They should not see a project you meant to keep out of this workspace, because that project should not exist yet.

If they cannot create the task, the role is too tight for week one. Add the create permission for the people doing the work, not for the whole organization. If they can also invite a stranger, the role is too loose. Take member management off. That is the only permission edit the first day needs. A full custom-role exercise can wait until this loop is dull.

Name the workspace and the project in the same language the team uses in conversation. If they say "the redesign" and the project is called "PRJ-04," they will create a second project. Rename now, before tasks accumulate under the code.

Then do real work. The next configuration change should be provoked by a task that did not fit, not by a checklist of features you have not needed.

Conclusion

Set up a workspace, add the people who belong in it, create one project, give it a few sections and a short status list, and enter this week's tasks. Leave extra workspaces, custom roles, and guest access until the first project is real. The product you are setting up is /pms.

One mistake to avoid

Do not create the second workspace, the guest, and the custom role on the same morning as the first project. You will not know which of them caused a person to see the wrong tasks. Finish the single-workspace loop, then change one boundary at a time.

If the second person completes the loop, write down the workspace name and the project name where the team already looks for links. A setup that lives only in one person's memory gets recreated next week as a duplicate project.