Wrike
Wrike is a work and project management tool for teams. It supports planning, task assignment, progress tracking, real-time collaboration, and reporting, suitable for marketing, product, and IT teams.
- Get Started
- Learn the Basics
- Level Up Your Work
- Monitor Your Work
- Manage Your Account
- Work Securely
- Enhance Your Wrike Experience
- Learn About Wrike Plans
Get Started With Wrike
- Learn Wrike’s building blocks: spaces → folders/projects → tasks.
- Get your first project running with a simple workflow.
- Adopt “My To-Do” and search to stay on top of work.
- Know what “sharing + access roles” change (and what they don’t).
1) Purpose & Outcome
This section gets a new user from “logged in” to “shipping real work” using Wrike’s core structure. The goal is not perfection—just a clean, repeatable path to organize tasks and collaborate.
- Decide where work will live: Personal space vs a team space.
- Create a small project with a handful of tasks you can finish this week.
- Assign owners and due dates so work is visible and trackable.
- Start using comments/mentions for decisions instead of side chats.
- Use dashboards/reports later—first, get the basics right.
2) Who this is for + When to use
Best for first-time Wrike users, new team members, or anyone inheriting a messy workspace. Use it when you need a clear personal workflow (My To-Do) and a clean team structure (spaces/projects).
- If you’re an individual: focus on Personal space + My To-Do.
- If you’re a team member: ask which space to use before creating projects.
- If you’re a manager: start with one pilot project and a simple status flow.
- If you’re an admin: pair this with “Manage Your Account” for setup.
3) Where in navigation + Related tabs
Wrike is organized around the left sidebar and your current location (space/folder/project). You’ll jump between building work (Learn the Basics), improving workflows (Level Up Your Work), and tracking progress (Monitor Your Work).
4) Mental model / Flow
Wrike’s core model is: a space contains folders and projects; projects/folders contain tasks; tasks are the actionable units. You can tag/organize tasks under multiple locations when needed (e.g., a task appears in a project and a folder).
- Choose the right space (team area) for visibility and ownership.
- Create a project for an initiative with a timeline.
- Add tasks (action items) and assign owners/due dates.
- Use statuses to reflect progress and drive reporting.
- Share items and set access roles to control what collaborators can do.
5) Objects & Terms (starter glossary)
These terms show up everywhere in Wrike. Learn them early so you can follow tutorials and avoid creating work in the wrong place.
- Space: team/department area (also where tools like dashboards can live).
- Folder: organizational container (not actionable).
- Project: group of tasks with project attributes (timeline/progress).
- Task: actionable work item with assignee/status/dates.
- My To-Do: your personal view of active tasks (including tasks you add there).
- Access role: permissions on a shared folder/project/space (Full/Editor/Limited/Read-only).
6) Lifecycle / State machine
Tasks typically move through statuses (e.g., New → In Progress → Completed). Exact status names vary by workflow, but the rule is consistent: status changes are what drive visibility in views, dashboards, and reports.
- Define “done” using the Completed state consistently.
- Keep “blocked” explicit (a status or a custom field) if your team needs it.
- Don’t use comments as a substitute for status changes—do both.
- Expected outcome: anyone can tell task progress at a glance.
7) Core jobs-to-be-done (JTBD)
These are the most common “first week” jobs in Wrike. If you can do these, you can run day-to-day work confidently.
- Create a task and place it in the correct space/project.
- Assign the task, set dates, and clarify next action in the description.
- Comment + @mention to request input or confirm decisions.
- Add existing tasks to a folder/project/space when reorganizing work.
- Use My To-Do to manage your personal workload.
- Search to find items fast (tasks vs folders/projects).
8) Happy path workflow #1: Create a first project (6–8 steps)
Use this when you want a clean “pilot project” that a small team can run immediately.
- Create or choose a space where the project belongs.
- Create a project and name it clearly (Outcome + Date/Phase).
- Add 5–10 tasks for the next 1–2 weeks (one owner each).
- Set due dates and confirm the status workflow you’ll use.
- Share the project with the team and set suitable access roles.
- Post a kickoff comment with goals + how updates should happen.
9) Happy path workflow #2: Manage your day with My To-Do (6–8 steps)
Use this to keep personal accountability even when tasks live across many projects.
- Open My To-Do and scan active tasks assigned to you.
- If a task you need isn’t assigned to you, add it to My To-Do (manual add).
- Sort by due date; identify the top 3 tasks for today.
- Open each task and write the next action in the task description or a comment.
- Update status as you start/finish work; @mention blockers early.
- At end of day, confirm what’s done and what needs a date change.
10) Decision points (A/B)
Use these quick choices to avoid building the wrong structure early.
| Situation | If A… | Then do… | If B… | Then do… |
|---|---|---|---|---|
| Where should work live? | It’s personal | Use Personal space + My To-Do | It’s team work | Use a team space + shared project |
| Organizing container | Needs timeline/progress | Create a Project | Just grouping content | Create a Folder |
| Visibility issue | Someone can’t see it | Check sharing + access role | They see it but can’t edit | Upgrade access role (if allowed) |
| Reorganizing tasks | Same task needed in many places | Add task to folder/project/space | Task belongs only once | Keep single location, link in comments |
11) Guardrails: Do / Don’t + Common mistakes
Most beginners struggle with structure and visibility. These guardrails keep the workspace clean and collaboration smooth.
Do
- Do keep one clear owner per task.
- Do use statuses as the “source of truth” for progress.
- Do share at the right level (project/folder/space) and verify access roles.
Don’t
- Don’t create duplicate projects for every small variation—start simple.
- Don’t hide decisions in private messages—use task comments.
- Don’t rely on titles only; add context in description/custom fields when needed.
Common mistakes (and how to avoid)
- Work created in the wrong space: confirm location before creating tasks/projects; move/tag if needed.
- “I can’t see it” confusion: check sharing and access roles first.
- Status never updated: add “status update” to daily routine; keep it lightweight.
- Too many folders/projects: start with a minimal structure and evolve after 1–2 weeks.
- Unassigned tasks: assign an owner or explicitly park in a backlog with a clear rule.
12) What good looks like + Checklists + Practice lab + Official docs links
Use this mini-lab to validate you’re using Wrike correctly, then keep the checklists as your weekly hygiene routine.
- Projects have clear goal + owners.
- Tasks have assignee, dates, and next action.
- Status reflects reality within 24 hours.
- Work is discoverable via search and location.
Checklist
- Right space selected
- Project vs folder chosen
- Owners confirmed
- Status flow agreed
- Sharing/access roles verified
- Overdue tasks reviewed
- Statuses updated
- Duplicates removed
- Naming consistent
- Key work visible in My To-Do
Practice lab (10 min)
- Create 1 project in the correct space.
- Add 6 tasks; assign owners and due dates.
- Tag 1 task into an additional folder/project if needed.
- Update one task status to “In Progress”.
- Post a kickoff comment and @mention 1 teammate.
Official docs links (titles)
- Get Started With Wrike (category overview)
- Step 2: Learn the Fundamentals
- Creating Projects
- Creating a Task
- Folders in Wrike
- Spaces in Wrike
- My To-Do
- Access Roles in Wrike
Learn the Basics
- Build the core structure: spaces, folders, projects, tasks.
- Create tasks from different views (Workspace/Table/Board/Gantt).
- Understand “tagging” tasks into multiple locations.
- Use search commands to find work fast.
1) Purpose & Outcome
This tab teaches the “alphabet” of Wrike: what each work item is, and how to create and place it correctly. The outcome is that you can create tasks/projects and keep them discoverable for your team.
- Pick the right container (space vs folder vs project).
- Create tasks efficiently from your preferred view.
- Use consistent naming and lightweight structure.
- Understand how tasks can live in multiple locations.
- Expected outcome: less lost work, less “where is that?”
2) Who this is for + When to use
For everyday Wrike users (contributors/managers) who build and update work items. Use this whenever you’re unsure whether something should be a project, folder, or task—or when your workspace feels messy.
- New users onboarding to an existing space.
- Anyone migrating from spreadsheets or chat-based tasking.
- Teams standardizing how they create projects and tasks.
- People who need faster search and navigation habits.
3) Where in navigation + Related tabs
Most basics are performed in the workspace views while inside a space/folder/project. Improving consistency later belongs to “Level Up Your Work”, while tracking belongs to “Monitor Your Work”.
4) Mental model / Flow
Think of Wrike as a “map” (spaces/folders/projects) plus “work” (tasks). When you create work, always answer: where does it live, who owns it, and how will progress be reported?
- Navigate into the correct space and container.
- Create the work item (project/task) from the view you’re using.
- Assign owners and dates; choose status that reflects reality.
- Place/tag the item in the right location(s).
- Use comments/attachments for collaboration and proof.
5) Objects & Terms
Wrike’s docs emphasize spaces, folders, projects, and tasks as the building blocks. Learn what each is for so you don’t overload one item type to do another’s job.
- Project: used to manage a group of tasks toward a goal.
- Folder: for organization (not an actionable item).
- Task: the unit of action; can be created from multiple views.
- Tag/Add to location: add an existing task to folders/projects/spaces.
- Search: find tasks vs folders/projects; can use commands.
6) Lifecycle / State machine
At the basics level, lifecycle means “how you reflect progress.” Status changes are the simplest and most important lifecycle control for tasks and projects.
- Start: status indicates new/ready.
- Active: status indicates in-progress/blocked.
- Finish: mark completed to keep reports accurate.
- Expected outcome: consistent reporting and less manual chasing.
7) Core jobs-to-be-done
If you can do these quickly, you’ll feel fluent in Wrike.
- Create a project and understand what it’s for.
- Create a task from the Workspace (+ button) and place it correctly.
- Create tasks from Table/Board/Gantt when you’re already in those views.
- Add an existing task to another folder/project/space (reorg without duplication).
- Use My To-Do as your daily source of truth.
- Use search commands to find items and narrow results.
8) Happy path workflow #1: Create tasks from the Workspace (6–8 steps)
Fastest path to capture work, then place it correctly.
- Click the + button at the top of the workspace.
- Select Task and enter a clear title.
- Confirm the location (by default it may land in your Personal space).
- Assign an owner; add due date and priority context in description.
- Tag/add the task to the correct folder/project if needed.
- Post a comment with the first next action and @mention stakeholders.
9) Happy path workflow #2: Reorganize work without duplicates (6–8 steps)
Use when you need an existing task to appear under a different project/folder/space.
- Open the target folder/project/space in Table view.
- Click + Item (or the add row control).
- Paste the task’s permalink or select the existing task.
- Confirm the task now appears in the new location.
- Remove the old location only if it was truly wrong (don’t break context).
- Notify the assignee in a comment if the change impacts reporting.
10) Decision points (A/B)
| Situation | If A… | Do… | If B… | Do… |
|---|---|---|---|---|
| Work has a timeline | Yes | Create a Project | No | Use a Folder + tasks |
| Need multiple views | Table users | Create tasks in Table view | Visual workflow | Create/manage in Board view |
| Task belongs in two places | Yes | Add to location (tag) | No | Keep single location; link references |
| Find items quickly | Know the name | Use search | Need filtering | Use views/filters (later: dashboards) |
11) Guardrails + Common mistakes
Basics are about keeping structure clean and predictable so others can collaborate without extra instructions.
Do / Don’t
- Do create work where the team expects it (correct space).
- Do use consistent naming (Outcome + noun + date).
- Do assign an owner and due date for actionable tasks.
- Don’t store project requirements only in chat—attach/link in tasks.
- Don’t duplicate tasks to move them—tag/add to locations.
- Don’t leave statuses stale for days.
Common mistakes
- Creating everything as projects → use folders for organization-only.
- Tasks without owners → assign or park in a clear backlog.
- Wrong default location → verify personal space vs team space.
- Overusing tags → keep tagging purposeful (reporting/visibility).
- Searching only one way → learn workspace search commands for precision.
12) What good looks like + Checklists + Practice lab + Official docs links
- Each project has a clear scope and owners.
- Tasks are in correct location(s).
- Search returns clean, unambiguous results.
- Work items don’t multiply unnecessarily.
Checklist
- Correct space selected
- Project vs folder chosen
- Task titles consistent
- Owners assigned
- Dates set
- Duplicate tasks removed
- Statuses reflect reality
- Locations make sense
- Key links/attachments present
- Searchability tested
Practice lab (12 min)
- Create 1 project and 1 folder in a team space.
- Create 6 tasks (2 from Workspace, 2 from Table, 2 from Board).
- Add 2 existing tasks to another location (tag).
- Use search to find a task by exact phrase.
- Update 2 task statuses and comment an update.
Official docs links (titles)
- Step 2: Learn the Fundamentals
- Creating Projects
- Folders in Wrike
- Creating a Task (Workspace/Table/Board/Gantt)
- Adding Tasks to Folders, Projects, and Spaces
- My To-Do
- Workspace Search Commands
Level Up Your Work
- Make work consistent using shared structure and fields.
- Adopt dashboards, time tracking, and better views when ready.
- Use spaces and tools thoughtfully (avoid clutter).
- Automate or integrate later once your workflow is stable.
1) Purpose & Outcome
This tab helps you evolve from “we track tasks” to “we run a reliable process.” You’ll add structure (spaces, fields), visibility (dashboards), and measurable habits (time tracking/reporting) without overwhelming the team.
- Standardize how work is created and labeled.
- Improve visibility with dashboards and reporting basics.
- Introduce time tracking only after task hygiene is stable.
- Choose add-ons/integrations based on real pain points.
- Expected outcome: fewer exceptions, clearer status, faster coordination.
2) Who this is for + When to use
For team leads, project owners, and power users. Use it after 1–2 weeks of basic usage, when you start asking: “How do we keep things consistent and easy to report?”
- Teams adding multiple projects per month.
- Managers who need reliable rollups and views.
- Anyone responsible for dashboards and reporting.
- Admins planning workspace improvements (pair with Manage Your Account).
3) Where in navigation + Related tabs
You’ll work inside spaces/projects and also in space tools (like dashboards). For account-wide controls (like managing all custom fields), go to Settings under account management.
4) Mental model / Flow
Leveling up is about adding structure in layers: first consistent work items, then consistent metadata (fields), then consistent visibility (dashboards/reports), and finally automation/integrations.
- Confirm your baseline workflow (statuses + ownership) works.
- Add a small set of shared custom fields (only what you will use).
- Build a dashboard to monitor the workflow and exceptions.
- Add time tracking categories only if you’ll use the data.
- Automate/Integrate when the process is stable.
5) Objects & Terms
These terms show up as you scale your workflow and reporting.
- Dashboard: a collection of widgets; belongs to one space but can pull data from many.
- Widget: a block on a dashboard that shows filtered work or metrics.
- Custom field: extra metadata you can add to tasks/projects for reporting.
- Time tracking category: labels for time entries (useful for reporting).
- Report: a structured output built from templates or custom criteria.
6) Lifecycle / State machine
As you scale, lifecycle becomes more than statuses: it’s also “what fields must be present at each stage” and “who updates what.” If your docs/workflow doesn’t define it, keep it simple.
- Define “ready to start” criteria (e.g., owner + date + brief).
- Define “done” criteria (e.g., proof link/attachment + status completed).
- Keep transitions lightweight; avoid too many custom statuses early.
- Expected outcome: consistent reporting and less rework.
7) Core jobs-to-be-done
These jobs improve consistency and executive visibility without heavy process overhead.
- Build a dashboard that highlights overdue work and active priorities.
- Introduce a minimal set of custom fields used by everyone.
- Create a report template for weekly status reviews.
- Add time tracking categories if time reporting matters.
- Organize dashboards within a space so teams can find them.
- Decide which integrations are worth enabling for collaboration.
8) Happy path workflow #1: Create a dashboard for weekly tracking (6–8 steps)
Use this when you need one place to monitor priorities and exceptions.
- Choose the space that “owns” the dashboard.
- Open space Tools and access Dashboards.
- Create a dashboard with a clear name (Team + Purpose).
- Add 2–4 widgets: Overdue, Due this week, In progress, Needs review.
- Ensure widgets pull from the right spaces/projects (not too broad).
- Share the dashboard or confirm access within the space.
9) Happy path workflow #2: Manage custom fields responsibly (6–8 steps)
Use when you need better reporting but want to avoid a field explosion.
- List the 3–5 questions you want to answer (e.g., priority, client, type).
- Create only the fields required to answer those questions.
- Add fields to the relevant spaces/projects (not everywhere).
- Define who maintains each field (owner vs requester).
- Audit usage after 2 weeks—remove fields no one uses.
- Document field meaning in a short “how to fill” note.
10) Decision points (A/B)
| Situation | If A… | Do… | If B… | Do… |
|---|---|---|---|---|
| Need visibility | Daily triage | Use Dashboards | Formal updates | Use Reports |
| Fields needed? | Yes, for reporting | Create few custom fields | No clear use case | Don’t add fields yet |
| Time tracking | Billable/chargeback | Enable categories + routine | Not required | Skip to avoid overhead |
| Automation | Repeated manual steps | Consider Integrate/recipes | Process still changing | Wait; stabilize first |
11) Guardrails + Common mistakes
Scaling is where teams accidentally create complexity. Keep changes small, measured, and reversible.
Do / Don’t
- Do start with 1 dashboard per team space, not dozens.
- Do keep custom fields to the minimum set that drives decisions.
- Do review and delete unused fields/widgets regularly.
- Don’t build dashboards before task ownership/status hygiene exists.
- Don’t add time tracking if no one will review the data.
- Don’t automate a broken process—fix the process first.
Common mistakes
- Too many dashboards → consolidate around decisions.
- Custom fields everywhere → scope fields to specific spaces/projects.
- Reports that nobody reads → define audience and cadence first.
- Time tracking without categories/rules → define categories and expectations.
- Integrations enabled without governance → assign an owner for each integration.
12) What good looks like + Checklists + Practice lab + Official docs links
- Dashboards answer clear questions.
- Fields are consistent and audited.
- Reports support a real meeting/cadence.
- Tooling adds clarity, not clutter.
Checklist
- Baseline workflow stable
- Owners/dates used
- Statuses updated
- Need for visibility identified
- Audience defined
- Dashboard reviewed weekly
- Unused widgets removed
- Fields audited
- Reports aligned to meetings
- Time data reviewed (if used)
Practice lab (10–15 min)
- Create 1 dashboard in a space.
- Add 3 widgets (Overdue, Due this week, In progress).
- Create 2 custom fields and apply to a project.
- Fill fields on 5 tasks consistently.
- Export/share a weekly report concept with your team lead.
Official docs links (titles)
- Dashboards
- Creating Reports
- Managing All Custom Fields in the Account
- Using Time Tracking Categories
- Adding and Deleting Time Tracking Categories
Monitor Your Work
- Use dashboards for daily/weekly visibility.
- Use reports for structured status reviews.
- Rely on statuses, due dates, and ownership for accuracy.
- Keep monitoring lightweight: exceptions first (overdue/blocked).
1) Purpose & Outcome
Monitoring turns Wrike data into decisions. You’ll set up a simple visibility system so you can answer: “What’s late? What’s next? What needs attention?”
- Build dashboards that highlight exceptions.
- Create reports for recurring reviews.
- Keep data accurate through consistent status/date updates.
- Expected outcome: faster reviews, fewer surprises.
2) Who this is for + When to use
For project owners, team leads, and anyone responsible for weekly updates. Use it once you have at least 1 active project and tasks with owners and dates.
- Team leads doing weekly standups/reviews.
- Managers tracking multiple projects.
- PMs who need a consistent reporting rhythm.
- Anyone who needs visibility across spaces.
3) Where in navigation + Related tabs
Dashboards live under the sidebar and within space tools; reports are created from reporting areas. For permissions/security around visibility, cross-link to Work Securely and Manage Your Account.
4) Mental model / Flow
Monitoring is a loop: define what “good data” looks like, surface exceptions automatically, then review and act. Dashboards are best for fast scanning; reports are best for structured, repeatable reviews.
- Ensure tasks have owners, due dates, and statuses.
- Create a dashboard to highlight exceptions (overdue/blocked).
- Create a report for weekly status (by project/team).
- Review, update statuses/dates, and assign follow-ups.
- Repeat on a cadence (daily/weekly).
5) Objects & Terms
These terms are used frequently in monitoring-focused docs.
- Dashboard: collection of widgets (belongs to one space but can show data from many).
- Widget: the “view” unit inside dashboards (filtered list/metrics).
- Report template: predefined report structure you can reuse.
- Filters: narrow work by status, assignee, dates, fields.
- Metrics: numbers derived from work items (depends on widget/report type).
6) Lifecycle / State machine
Monitoring depends on lifecycle signals: statuses, due dates, and completion. If these aren’t maintained, dashboards and reports become noise.
- Use “Completed” consistently for finished work.
- Move tasks forward as work progresses (don’t leave in “New”).
- Update dates when scope changes—don’t just let tasks go overdue.
- Expected outcome: your dashboards reflect reality.
7) Core jobs-to-be-done
Your goal is to reduce manual status chasing.
- Create a dashboard for daily triage.
- Create a report for weekly review.
- Scan for overdue work and assign actions.
- Identify workload risks early (too many tasks per person, too many overdue).
- Keep stakeholders aligned using shareable views.
8) Happy path workflow #1: Daily triage dashboard (6–8 steps)
Use for quick daily scans (5–10 minutes).
- Open the team space and go to Dashboards.
- Create (or open) a dashboard named “Daily Triage”.
- Add widgets: Overdue, Due today, Blocked/In progress.
- Review overdue tasks; decide: re-date, reassign, or escalate.
- Comment and @mention owners with the next action.
- Update statuses/dates on the spot.
9) Happy path workflow #2: Weekly status report (6–8 steps)
Use for consistent, repeatable reporting (30–60 minutes weekly meeting prep).
- Create a report using a template (or build a simple custom one).
- Scope it to the relevant spaces/projects.
- Group by status and/or assignee for clarity.
- Review key sections: completed, in progress, overdue.
- Capture decisions in comments (tasks that need escalation or scope change).
- Share the report view with stakeholders.
10) Decision points (A/B)
| Situation | If A… | Do… | If B… | Do… |
|---|---|---|---|---|
| Need speed | Quick scanning | Use Dashboards | Formal documentation | Use Reports |
| Scope too broad | Too many items | Narrow filters (space/project/status) | Still messy | Split by team or workflow stage |
| Overdue items | Real delay | Re-date + explain in comment | No longer needed | Close/cancel with clear note |
| Blocked work | Needs decision | Escalate via @mention + owner | Needs info | Create subtask + assign researcher |
11) Guardrails + Common mistakes
Monitoring is only as good as your underlying data. Keep the system honest.
Do / Don’t
- Do enforce owners and dates on actionable tasks.
- Do review exceptions first (overdue/blocked).
- Do keep dashboards lightweight (few high-signal widgets).
- Don’t create dashboards for every small question—start with 1–2.
- Don’t let tasks sit overdue without a decision.
- Don’t hide status updates in chat—use task status + comment.
Common mistakes
- Dashboards show junk → filters too broad; tighten scope.
- Reports are outdated → statuses/dates not maintained.
- Too many widgets → keep only what you act on weekly.
- Overdue is ignored → define a rule: re-date or close.
- No cadence → schedule daily scan + weekly report.
12) What good looks like + Checklists + Practice lab + Official docs links
- Overdue tasks drop week-over-week.
- Dashboards are reviewed daily/weekly.
- Reports map to real meetings.
- Data is trustworthy (owners/dates/status).
Checklist
- Tasks have owners
- Dates set
- Status flow defined
- Dashboard scoped
- Stakeholders identified
- Overdue reviewed
- Blocked escalated
- Statuses updated
- Reports shared
- Widgets cleaned up
Practice lab (10 min)
- Create a “Daily Triage” dashboard.
- Add 3 widgets (Overdue/Due soon/In progress).
- Pick 5 tasks; ensure owner/date/status are correct.
- Resolve 2 overdue tasks (re-date or complete).
- Share the dashboard with a teammate.
Official docs links (titles)
- Dashboards
- Creating Reports
- Using Sections to Organize Your Widgets
Manage Your Account
- Manage users, licenses, and admin rights safely.
- Understand user types vs access roles vs admin permissions.
- Customize access roles only when you have a clear need.
- Keep workspace governance: spaces, fields, and ownership.
1) Purpose & Outcome
Account management keeps Wrike usable as more people join. You’ll learn how to add/manage users, control permissions, and avoid common admin mistakes that cause access issues or clutter.
- Onboard users with the right license and rights.
- Set admin permissions deliberately (least privilege).
- Use access roles to control what people can do in shared areas.
- Maintain governance for spaces and account-wide fields.
- Expected outcome: fewer access problems, cleaner workspace.
2) Who this is for + When to use
For account owners, admins, and workspace managers. Use it when onboarding teams, setting permissions, or troubleshooting “why can/can’t this person do X?”
- Account owner setting initial governance.
- Admins adding/deactivating users.
- Space admins managing visibility and roles.
- Leads who need controlled sharing and edits.
3) Where in navigation + Related tabs
Most admin actions start from your profile menu → Settings and then “Account management” sections (e.g., user management, access roles). Security-specific settings live under “Work Securely”.
4) Mental model / Flow
Wrike permissions are layered. A user’s capabilities depend on (1) their user type/license, (2) admin permissions if they are an admin, and (3) their access role in specific shared spaces/projects/folders.
- Decide user type/license (what features they can use).
- Decide whether they’re an admin; assign only needed admin permissions.
- Share the relevant space/project/folder with the user.
- Assign an access role (Full/Editor/Limited/Read-only).
- Verify by asking the user to open/edit a test item.
5) Objects & Terms
These admin terms are easy to mix up. Keep them distinct to troubleshoot faster.
- User type: baseline rights and feature access for users.
- Admin permissions: what an admin can configure (may be controlled on some plans).
- Access role: what a user can do inside a shared folder/project/space.
- Account owner: the primary admin/owner (one per account).
- Space admin: manages a specific space and access roles inside it.
6) Lifecycle / State machine
Admin lifecycle is about user accounts: invite → active → deactivated/deleted. Choose the right end state to preserve history and keep reporting stable.
- Deactivate when someone may return or you want to preserve history cleanly.
- Delete when you must remove access permanently (understand data implications).
- Expected outcome: safe offboarding without breaking ongoing work.
7) Core jobs-to-be-done
As an admin/workspace manager, these are your most common “real work” tasks.
- Add new users and assign correct license type.
- Make a user an admin (only if needed) and restrict permissions where possible.
- Create or customize access roles when standard roles aren’t enough.
- Change access roles on shared projects/folders/spaces.
- Manage account-level custom fields (audit and clean up).
- Set permissions for managing spaces (where supported).
8) Happy path workflow #1: Onboard a new user safely (6–8 steps)
Use this to avoid “new user has too much access” or “can’t do anything”.
- Add/invite the user via User Management.
- Assign the correct license/user type for their role.
- Decide if admin rights are needed; default to no.
- Share the relevant space/project/folder(s) with them.
- Set the appropriate access role (start restrictive, expand as needed).
- Ask them to verify: can they view, comment, edit, create?
9) Happy path workflow #2: Create a custom access role (6–8 steps)
Use only when standard roles don’t fit. Keep custom roles few and well-documented.
- Define the exact capability gap (what users need to do).
- Go to Settings → Account Management → Access Roles.
- Create a new access role with a descriptive name and description.
- Enable only the rights needed (least privilege).
- Test the role on a small pilot group.
- Roll out and document “when to use this role”.
10) Decision points (A/B)
| Situation | If A… | Do… | If B… | Do… |
|---|---|---|---|---|
| User needs capability | Within a space/project | Adjust access role | Account-wide setting | Adjust user type/admin permissions |
| Offboarding | May return | Deactivate | Permanent removal | Delete (if policy requires) |
| Role mismatch | Standard roles work | Use Full/Editor/Limited/Read-only | Truly unique needs | Create custom role |
| Space governance | Need centralized control | Enable “manage spaces” permissions (where available) | Team-managed | Keep ownership with space admins |
11) Guardrails + Common mistakes
Admin changes scale fast—mistakes impact everyone. Treat changes like production deployments.
Do / Don’t
- Do apply least privilege and expand only when needed.
- Do test permission changes with a pilot user.
- Do keep a short “roles glossary” for your org.
- Don’t make everyone an admin for convenience.
- Don’t create many custom roles without governance.
- Don’t change licensing/user types without understanding impact on features.
Common mistakes
- Confusing user type with access role → troubleshoot layer-by-layer.
- Granting broad admin rights → restrict and document.
- Custom roles proliferation → consolidate and audit quarterly.
- Users can’t see items → sharing missing; fix share before changing roles.
- Spaces unmanaged → define who can create/manage spaces.
12) What good looks like + Checklists + Practice lab + Official docs links
- New users are productive in 1 day.
- Roles are few, documented, and audited.
- Admins have controlled permissions.
- Access issues are resolved via sharing/roles quickly.
Checklist
- Org policy for admins
- Standard roles defined
- Pilot group identified
- Space ownership agreed
- Offboarding process defined
- User list audited
- Admins reviewed
- Custom roles reviewed
- Space permissions validated
- Fields audited (if relevant)
Practice lab (12 min)
- Review your user list; identify one test user.
- Share a project with the user and set a restrictive access role.
- Ask them to confirm what they can/can’t do.
- Adjust role to match the job (only what’s needed).
- Document the chosen role in a short internal note.
Official docs links (titles)
- Manage Your Account (category overview)
- User Management (section overview)
- User Types vs. Access Roles and Admin Permissions
- Access Roles in Wrike
- Creating and Customizing Access Roles
- Changing Access Roles
- Account Admins in Wrike
- Account Admin Rights
- Managing Spaces at the Account Level
- Managing All Custom Fields in the Account
Work Securely
- Security is mostly about identity + admin controls + access roles.
- Use least privilege and audit sharing regularly.
- Enterprise features may add controlled admin permissions.
- If a security module isn’t in your plan/docs, treat it as not applicable.
1) Purpose & Outcome
This tab helps you protect your workspace without slowing work down. You’ll learn which levers matter most: user types, admin permissions, and access roles.
- Reduce accidental exposure via correct sharing and roles.
- Separate “admin who configures” from “user who edits work”.
- Understand controlled admin permissions where available.
- Expected outcome: safer collaboration with fewer access surprises.
2) Who this is for + When to use
For account owners, admins, and space admins—especially in regulated environments. Use it before broad onboarding, and anytime you’re auditing who can see/edit sensitive work.
- New workspace rollout or org expansion.
- Handling client data or confidential projects.
- Preparing for internal audit or security review.
- Investigating unexpected access to items.
3) Where in navigation + Related tabs
Security controls are typically in Settings (account management) and in sharing dialogs on spaces/projects/folders. Pair this with Manage Your Account for user/admin operations.
4) Mental model / Flow
Security is enforced through layers: identity (who the user is), admin permissions (what configuration they can do), and access roles (what they can do in shared content).
- Confirm identity setup (SSO/OTP/etc.) (Not applicable if not in your docs/plan).
- Minimize admins; restrict admin permissions where possible.
- Use access roles for least privilege within spaces/projects/folders.
- Audit sharing on sensitive spaces/projects routinely.
- Document exceptions (why someone needs elevated access).
5) Objects & Terms
Security-related docs focus on who can do what, and who can configure what.
- Access roles: Full/Editor/Limited/Read-only (controls actions in shared items).
- User types: baseline capabilities and feature access.
- Admin permissions: configuration rights; may be controlled in Enterprise plans.
- Account owner: top-level admin (single owner per account).
- Space admin: can manage access roles in the space.
6) Lifecycle / State machine
Security lifecycle is about access over time: onboarding, role changes, offboarding. Treat each as a change that should be verified.
- Onboard: assign minimal access → verify → expand if needed.
- Role change: document reason → apply → retest.
- Offboard: deactivate/delete per policy → remove from shared areas if required.
- Expected outcome: access matches employment/engagement status.
7) Core jobs-to-be-done
These jobs are how you keep the workspace secure day-to-day.
- Set access roles correctly on sensitive spaces/projects.
- Restrict admin permissions to a small group.
- Understand differences between user type vs access role vs admin permissions.
- Audit sharing to ensure only intended users have access.
- Use controlled admin permissions when available (Enterprise feature).
8) Happy path workflow #1: Secure a sensitive project (6–8 steps)
Use this when handling confidential work (client/legal/HR projects).
- Create or choose a dedicated space/project for the sensitive work.
- Limit sharing to the smallest required group.
- Assign restrictive access roles for non-owners (e.g., read-only/limited).
- Verify who can share/edit/delete within the space/project.
- Document the access policy in a pinned comment or project description.
- Review access weekly (remove anyone no longer needed).
9) Happy path workflow #2: Resolve “can’t edit” vs “can’t see” (6–8 steps)
Use this as a standard troubleshooting playbook.
- If user can’t see the item: check sharing first.
- If user can see but can’t edit: check access role.
- If role changes don’t help: check user type/license limitations.
- If admin action required: confirm whether they need admin permissions.
- Apply the smallest change that resolves the issue.
- Ask user to confirm the fix and document what changed.
10) Decision points (A/B)
| Situation | If A… | Do… | If B… | Do… |
|---|---|---|---|---|
| User can’t see item | Not shared | Share the space/project/folder | Shared but still hidden | Check user access/space membership rules |
| User can’t edit | Role too restrictive | Upgrade access role carefully | Policy requires restrict | Keep role; assign edits to owner |
| Admin rights | Needed for config | Grant minimal admin permissions | Not needed | Don’t grant admin; use access roles |
| Enterprise controls | Available | Use controlled admin permissions | Not in plan/docs | Not applicable for this tool/tab |
11) Guardrails + Common mistakes
Security failures often come from convenience decisions. Keep guardrails simple and consistent.
Do / Don’t
- Do use least privilege for roles and admin permissions.
- Do audit sharing for sensitive spaces regularly.
- Do document why someone has elevated access.
- Don’t make “everyone full access” the default.
- Don’t give admin rights to solve content-level permission problems.
- Don’t rely on verbal policy—write it in the space/project.
Common mistakes
- Confusing access roles with user types → troubleshoot layers.
- Too many admins → reduce, then add controlled permissions if available.
- Sensitive work in public spaces → isolate into dedicated space/project.
- No access reviews → add recurring reviews to team routine.
- Fixing access by over-granting → apply the smallest change.
12) What good looks like + Checklists + Practice lab + Official docs links
- Admins are few and controlled.
- Access is explainable and minimal.
- Sensitive areas are isolated.
- Access requests follow a clear process.
Checklist
- Sensitive scope defined
- Space/project chosen
- Owners identified
- Sharing limited
- Role policy documented
- Access verified by user
- Admins reviewed
- Exceptions documented
- Weekly access review scheduled
- Offboarding process ready
Practice lab (8–10 min)
- Pick a test project and review who it’s shared with.
- Set one user to a restrictive access role.
- Ask them to confirm view/comment/edit abilities.
- Fix any mismatch using role (not admin rights).
- Write a 2–3 line access policy in the project description.
Official docs links (titles)
- User Types vs. Access Roles and Admin Permissions
- Access Roles in Wrike
- Changing Access Roles
- Enterprise Account Admin Permissions
- Account Admin Rights
Enhance Your Wrike Experience
- Integrations extend Wrike where you already work (Slack/Teams).
- Wrike Integrate enables automation recipes across apps.
- Start with one high-value integration and expand gradually.
- Keep governance: owner, scope, and security review.
1) Purpose & Outcome
This tab helps you connect Wrike to your team’s collaboration tools and automate repeated steps. The goal is smoother flow: fewer context switches, fewer manual updates.
- Set up a collaboration integration (Slack or Microsoft Teams).
- Use integrations to create tasks and receive notifications.
- Evaluate automation with Wrike Integrate for repeatable workflows.
- Expected outcome: faster collaboration and fewer missed updates.
2) Who this is for + When to use
For team leads, ops, and power users once core workflow is stable. Use it when you notice repeated manual steps or heavy chat-based task creation.
- Teams living in Slack/Teams and needing Wrike visibility.
- Ops teams automating standard intake and routing.
- Managers wanting fewer “please update Wrike” reminders.
- Admins responsible for add-ons and governance.
3) Where in navigation + Related tabs
Integrations may be configured from settings or integration entry points, and used inside chat tools. For permission and governance, cross-link to Manage Your Account and Work Securely.
4) Mental model / Flow
Enhancements come in two layers: (1) integrations that bring Wrike into another tool, and (2) automation that connects triggers to actions (recipes). Start with the simplest integration first.
- Pick one collaboration tool (Slack or Teams) to start.
- Define the exact outcome you want (notifications, create tasks, preview items).
- Enable integration for a pilot channel/team.
- Document simple usage norms (“create tasks from X channel”).
- If repeatable: build an automation recipe (Integrate) and monitor it.
5) Objects & Terms
These terms appear in Wrike’s integration docs and help center articles.
- Integration: native connection (e.g., Slack/Teams) for notifications and actions.
- Notification: Wrike updates delivered to chat tools.
- Preview: viewing Wrike items in chat.
- Wrike Integrate: add-on for cross-app automation.
- Recipe: automation flow (trigger → conditions → actions).
6) Lifecycle / State machine
Integrations have their own lifecycle: enable → pilot → roll out → audit. Automation adds monitoring: recipes can fail if permissions change or APIs change.
- Pilot in one team/channel first.
- Roll out after success and documentation.
- Audit quarterly: owners, scopes, and whether value still exists.
- Expected outcome: enhancements remain useful and safe over time.
7) Core jobs-to-be-done
Enhancements are about removing friction in collaboration and repeatable work.
- Receive Wrike notifications in Slack/Teams for faster response.
- Create tasks from chat to capture work quickly.
- Preview tasks/projects/folders in chat so stakeholders can follow context.
- Automate routing and updates with Integrate recipes.
- Set governance: who owns and maintains integrations.
8) Happy path workflow #1: Start with Slack integration (6–8 steps)
Use when your team lives in Slack and needs Wrike visibility.
- Confirm your team’s Slack workspace and channel(s) for pilot.
- Enable/connect the Wrike–Slack integration for a pilot group.
- Set up basic notifications (mentions, assignments, status changes).
- Test creating a task from Slack for a real request.
- Test previewing a Wrike item link in Slack.
- Document 2–3 usage rules (where to create tasks, how to tag location).
9) Happy path workflow #2: Build an Integrate recipe (6–8 steps)
Use when you have a repeated cross-app workflow (intake, routing, notifications).
- Define the trigger (e.g., form submission or status change).
- Open Wrike Integrate and create a new recipe.
- Configure trigger details (source app/event).
- Add actions (create task, update status, post message, etc.).
- Set conditions to reduce noise (only for certain types/fields).
- Test with 3 sample cases; monitor early failures.
10) Decision points (A/B)
| Situation | If A… | Do… | If B… | Do… |
|---|---|---|---|---|
| Need collaboration boost | Chat-based team | Start with Slack/Teams integration | Process automation | Use Wrike Integrate |
| Scope of rollout | Uncertain value | Pilot one channel/team | Proven value | Roll out with documentation |
| Automation complexity | Simple | One trigger + one action | Complex | Add conditions/steps gradually |
| Governance | No owner assigned | Stop and assign an owner | Owner exists | Proceed with audit schedule |
11) Guardrails + Common mistakes
Integrations and automations can create noise or risk if unmanaged. Keep guardrails tight.
Do / Don’t
- Do start with one integration and a small pilot.
- Do define what “success” looks like (time saved, fewer missed updates).
- Do document how/where tasks should be created from chat.
- Don’t blast notifications to many channels—target only what matters.
- Don’t automate without monitoring and ownership.
- Don’t ignore permissions changes—recipes can break when access changes.
Common mistakes
- Notification overload → reduce events or narrow scope.
- Tasks created in wrong location → enforce tagging rules/templates.
- No owner for integrations → assign a maintainer and audit cadence.
- Automation duplicates work → add conditions to prevent double-creation.
- Security review skipped → cross-check with Work Securely.
12) What good looks like + Checklists + Practice lab + Official docs links
- People act faster because updates surface where they work.
- Automations reduce manual steps without creating noise.
- Integrations have owners and documented usage.
- Security and permissions are reviewed regularly.
Checklist
- Clear use case
- Pilot scope defined
- Owner assigned
- Notification policy set
- Security reviewed
- Pilot feedback collected
- Noise reduced
- Docs updated
- Recipe monitored (if used)
- Quarterly audit scheduled
Practice lab (10–12 min)
- Enable Slack or Teams integration for a pilot.
- Create a task from chat and tag it to the right project.
- Trigger one notification (assignment or @mention).
- If available, draft a simple Integrate recipe idea (trigger → create task).
- Write a 5-line “how we use this integration” note.
Official docs links (titles)
- Wrike and Slack Integration
- Wrike and Microsoft Teams Integration
- Wrike Integrate
- Setting Up Integrations via Wrike Integrate
Learn About Wrike Plans
- Plan affects availability of features and admin controls.
- Use plan docs to avoid assuming a feature exists.
- Document your team’s “standard way of working” within plan constraints.
- Upgrade decisions should be tied to clear outcomes (not curiosity).
1) Purpose & Outcome
This tab helps newbies understand why some buttons/features may differ between accounts. You’ll learn how to check plan-specific behavior and avoid building processes that depend on unavailable features.
- Map your workflow to plan-supported features.
- Use plan docs to explain “why we can’t do that (yet)”.
- Make upgrade decisions based on measurable needs.
- Expected outcome: fewer surprises and smoother adoption.
2) Who this is for + When to use
For team leads, admins, and anyone comparing what they see to someone else’s workspace. Use when onboarding across different plan tiers or evaluating add-ons.
- New teams on Free/Team plans.
- Leads evaluating Business/Enterprise features.
- Admins explaining availability differences.
- Teams planning automation/integrations add-ons.
3) Where in navigation + Related tabs
Plan information is typically found in “Learn About Wrike Plans” help center sections. For admin settings influenced by plan, cross-link to Manage Your Account and Work Securely.
4) Mental model / Flow
Treat plan constraints as guardrails: build a baseline workflow that works for everyone, then add optional enhancements when your plan supports them.
- List your required outcomes (tracking, collaboration, reporting, security).
- Check which features are available in your plan.
- Build a baseline workflow using universally available features.
- Add optional features (dashboards, reports, admin controls) if supported.
- Review quarterly: does the plan still match your needs?
5) Objects & Terms
These plan terms influence what you can configure.
- Plan / subscription: determines feature availability.
- Legacy vs current plans: availability may be described differently in docs.
- Add-on: extra capability like Wrike Integrate.
- User type/license: impacts feature access for individuals.
- Enterprise controls: may include controlled admin permissions.
6) Lifecycle / State machine
Plan lifecycle is: evaluate → pilot → adopt → reassess. Tie changes to a real business outcome so upgrades don’t become tool churn.
- Evaluate using one pilot team/project.
- Adopt when value is proven (time saved, fewer errors).
- Reassess when workflow or headcount changes.
- Expected outcome: stable tooling decisions and predictable processes.
7) Core jobs-to-be-done
Plan knowledge supports better operations and onboarding.
- Explain feature differences without guesswork.
- Choose the right plan for governance/security needs.
- Decide whether add-ons like Integrate are worth it.
- Prevent building workflows that depend on unavailable features.
- Standardize “how we work in Wrike” for your plan.
8) Happy path workflow #1: Verify feature availability (6–8 steps)
Use when someone asks “why don’t I see that feature?”
- Identify the feature (name and where it should appear).
- Check the relevant help center article for availability notes/tables.
- Confirm your account’s plan tier and user type/license.
- Confirm whether it’s an add-on (e.g., Integrate).
- If available: check if permissions/admin settings are required.
- If not available: propose a workaround using baseline features.
9) Happy path workflow #2: Make an upgrade decision responsibly (6–8 steps)
Use when considering Business/Enterprise or add-ons.
- Write down the problem (e.g., need controlled admin permissions, automation).
- Define success metrics (time saved, risk reduced, visibility improved).
- Run a pilot using plan trial (if available) or a small test process.
- Estimate operational cost if you don’t upgrade (manual work, errors).
- Decide: upgrade, defer, or redesign the workflow.
- Document the decision and revisit on a set date.
10) Decision points (A/B)
| Situation | If A… | Do… | If B… | Do… |
|---|---|---|---|---|
| Feature missing | Plan limitation | Use workaround or evaluate upgrade | Permission limitation | Adjust roles/admin settings |
| Need automation | Repeatable workflow | Consider Integrate add-on | Process still evolving | Stabilize first |
| Security needs | High governance | Evaluate Enterprise controls | Basic needs | Use roles/sharing discipline |
| Reporting needs | Structured reviews | Use reports/dashboards if supported | Minimal needs | Use basic views + status hygiene |
11) Guardrails + Common mistakes
Most plan confusion comes from assumptions. Keep it evidence-based using official plan docs.
Do / Don’t
- Do check availability notes in help center articles.
- Do separate “plan problem” from “permission problem”.
- Do pilot before upgrading org-wide.
- Don’t promise a workflow that depends on unknown features.
- Don’t buy add-ons without a clear owner and use case.
- Don’t create complexity just because a feature exists.
Common mistakes
- Comparing to another company’s Wrike → plan and settings differ.
- Assuming everyone can create reports → user types may restrict it.
- Confusing roles vs licenses → troubleshoot systematically.
- Upgrading without adoption → define usage expectations and training.
- Ignoring legacy/current plan differences → read availability sections carefully.
12) What good looks like + Checklists + Practice lab + Official docs links
- Team knows what features are available and why.
- Workflows are designed within plan constraints.
- Upgrades are intentional and measured.
- Add-ons have owners and ROI.
Checklist
- Problem defined
- Success metrics set
- Plan checked
- Permissions checked
- Pilot scope chosen
- Pilot results recorded
- Decision documented
- Training plan made
- Governance owner assigned
- Revisit date scheduled
Practice lab (8 min)
- Pick one feature you’re unsure about (reports, controlled permissions, etc.).
- Find the official availability notes in a relevant help article.
- Identify whether the limitation is plan, user type, or access role.
- Write one workaround using baseline features.
- Share your findings with your team in a short note.
Official docs links (titles)
- Learn About Wrike Plans (category overview)
- Team Plan: Understanding Work Items
- Feature availability notes in: Creating a Task / Creating Reports (availability tables)