Deel

2) Mental model (access layers)

Think in layers: organization-wide admins, group-scoped admins, and people-managers. Start broad (Org Admin), then narrow (Group Admin), then assign manager roles only where needed.

1. Define the minimum set of admins.
2. Segment by group when possible (reduces risk).
3. Assign managers for approvals and direct reports.
4. Review access regularly (especially after org changes).

3) Objects & terms

These terms are referenced in the official articles about roles. Use them as your shared vocabulary with stakeholders.

• Org Admin: organization administrator permissions (broad control).
• Group Admin: group-scoped admin permissions (narrower scope).
• Manager role: manager responsibilities and access for direct reports.
• Direct reports: workers tied to a manager relationship.
• Approval flows: actions (like time off) that route to managers/admins.

5) Core jobs-to-be-done

These are the common tasks you’ll repeat as your company grows.

• Assign manager roles across teams.
• Explain what managers can do on Deel (and what they can’t).
• Grant group-admin permissions for delegated HR ops.
• Keep Org Admin list minimal and up-to-date.
• Handle escalations: “missing access” vs “wrong permissions”.
• Prepare for scale via SSO/SCIM (if applicable).

6) Happy path workflow #1 — Assign a manager role

Use this when a new manager needs to approve requests or manage their team inside Deel.

1. Confirm the person has a user account in the correct organization.
2. Identify who their direct reports are (worker relationships/structure).
3. Assign the manager role using the organization settings flow.
4. Ask the manager to log in and confirm they can see their team view.
5. Run a test: submit one request (e.g., time off) from a direct report.
6. Verify the manager can approve/decline and you receive the expected notification.

8) Decision points (A/B)

These are the most common access decisions that affect security and speed.

9) Common mistakes + guardrails

Most permission incidents are accidental. Treat these as “never again” rules.

• Mistake: too many Org Admins → Avoid: limit to 1–3 owners.
• Mistake: managers can’t approve → Avoid: verify role + direct reports mapping.
• Mistake: unclear group boundaries → Avoid: define groups before delegating.
• Mistake: no audit trail → Avoid: log role changes (who/when/why).
• Mistake: access not removed → Avoid: revoke on role change/offboarding.

2) Mental model (People as system-of-action)

Treat People as your “source of actions” even if it’s not your only source of truth yet. Profiles hold data; tasks and workflows drive work; structure/relations control visibility and manager flows.

1. Create or import worker profiles.
2. Collect required worker information (fields, forms, documents).
3. Assign tasks/onboarding checklist.
4. Automate follow-ups with Workflow Builder.
5. Maintain structure and relationships for reporting/approvals.

3) Objects & terms

These terms appear frequently in People Management articles and are the building blocks for HR workflows.

• Worker profile: the record for a worker inside Deel.
• Direct employee (HRIS) contract: a setup path for direct employees.
• Mass import: bulk creation for many direct employees.
• Tasks / onboarding checklist: assigned operational steps.
• Workflow Builder: automation for workflow tasks.
• Organization structure & worker relations: grouping and relationships used in People directory and org chart.

5) Core jobs-to-be-done

Use these as your standard playbook for day-to-day People Ops inside Deel.

• Create a direct employee (HRIS) contract/profile.
• Mass import direct employees.
• Collect worker information and required fields.
• Create and manage tasks for workers.
• Set up automation workflows / Workflow Builder tasks.
• Maintain org structure and worker relations.
• Bulk edit worker and payroll contract info (when needed).

6) Happy path workflow #1 — Add workers (manual → ready)

Use this when you’re adding a small number of workers and want a consistent “ready to operate” result.

1. Create the worker profile / direct employee setup as needed.
2. Collect worker information (required fields and any enabled demographics fields).
3. Assign tasks and/or a customized onboarding checklist.
4. Set manager roles and worker relations (so approvals route correctly).
5. Run one automated task with Workflow Builder (e.g., reminder or document request).
6. Verify the worker can complete their assigned steps and you can track status.

8) Decision points (A/B)

Pick the option that matches your scale and data maturity.

9) Common mistakes + guardrails

These issues are common when building a People hub quickly. Use the guardrails to keep data stable.

• Mistake: missing manager mapping → Avoid: set relations during onboarding.
• Mistake: duplicates after import → Avoid: standard identifiers + merge early.
• Mistake: tasks with unclear owners → Avoid: define task ownership in checklist.
• Mistake: automations without testing → Avoid: pilot Workflow Builder on one team.
• Mistake: bulk edits without audit → Avoid: use modification reasons/change log if enabled.

2) Mental model (policy → approval → balance)

Time off is a loop: policies define entitlements; approval rules route requests; approved requests update balances. Keep the loop tight and you’ll avoid disputes.

1. Create or customize a time off policy.
2. Set approval policy (who approves, in what order).
3. Workers submit requests.
4. Approvers review and decide.
5. Balances update; admins adjust only when needed.

3) Objects & terms

These are the key pieces referenced across the official time off articles.

• Time off policy: defines entitlement and rules.
• Approval policy: defines who can approve time off.
• Request: a submitted time off entry awaiting action.
• Balance: remaining entitlement after usage/adjustments.
• Direct employee time off: time off management path for direct employees.
• Contractor time off expectation: may differ; confirm policy approach.

5) Core jobs-to-be-done

These are the top repeatable admin/manager actions in Time Off.

• Create a custom time off policy for workers.
• Configure time off approval policies.
• Review and manage employee time off requests.
• Manage direct employee time off requests (if applicable).
• Adjust time off balances when corrections are needed.
• Clarify policy stance for contractors (where relevant).

6) Happy path workflow #1 — Set up Time Off (admin)

Use this when you’re enabling Time Off for the first time and want a safe default setup.

1. Decide your policy approach (standard vs custom policy).
2. Create the time off policy and confirm entitlement logic.
3. Configure the approval policy (manager, HR, or both).
4. Confirm managers are correctly assigned in People/structure.
5. Run a test request with a pilot worker.
6. Verify the request routes to the right approver and updates balance when approved.

8) Decision points (A/B)

These decisions control how strict your time off process is.

9) Common mistakes + guardrails

Time off failures are usually routing or policy ambiguity. Fix these early and everything gets easier.

• Mistake: wrong approver routing → Avoid: verify manager mapping and approval policy.
• Mistake: policies not documented internally → Avoid: publish a 1-page policy summary.
• Mistake: adjusting balances without context → Avoid:
• Mistake: ignoring stuck requests → Avoid:
• Mistake: unclear contractor expectations → Avoid:

2) Mental model (programs + cycles)

Treat Engage as a set of “cycles”: define a program (e.g., goals or a pulse survey), launch to a population, collect updates, then review outcomes and iterate.

1. Pick one module (Goals or Surveys) for a pilot.
2. Define who participates and who owns follow-up.
3. Run a short cycle (2–4 weeks) before scaling.
4. Review results and adjust prompts/process.

3) Objects & terms

Engage is organized into sub-areas in the official navigation. Use these as your mental “tabs within the tab”.

• Goals: goal-setting and tracking routines.
• Learning: learning programs or learning tracking area.
• Career: career development planning area.
• Surveys: feedback collection (pulse/engagement surveys).
• Engage admin and user management: who can create/manage programs.

5) Core jobs-to-be-done

These are the most common “what are we actually doing?” jobs for Engage.

• Launch a basic goals cycle for one team.
• Collect feedback using a simple survey.
• Define learning focus areas for a quarter.
• Support career conversations with a lightweight template/process.
• Set who can administer Engage programs and who can participate.
• Run a recurring cadence (monthly/quarterly) with consistent reminders.

6) Happy path workflow #1 — Run a pilot survey cycle

Use this when you want a low-risk way to start using Engage and prove value quickly.

1. Pick a pilot group (one team or department).
2. Define the survey goal (e.g., onboarding feedback, weekly pulse).
3. Decide who reviews results and who owns follow-up actions.
4. Launch the survey and set a deadline.
5. Monitor response rates and send reminders (if available in your process).
6. Review results and decide 1–2 actions to take.
7. Communicate outcomes back to participants (close the loop).

8) Decision points (A/B)

These decisions control adoption and the “manager burden” level.

9) Common mistakes + guardrails

Engage fails when people don’t see outcomes. Keep your loop tight.

• Mistake: launching too many programs → Avoid: one pilot at a time.
• Mistake: no owner for follow-ups → Avoid: assign action owners before launch.
• Mistake: collecting feedback then silence → Avoid: always share outcomes.
• Mistake: manager overload → Avoid: keep cycles simple and time-boxed.
• Mistake: unclear admin rights → Avoid: define Engage admin/user management rules.

2) Mental model (architecture → bands → cycle)

A stable compensation program typically starts with structure, then runs cycles. Job architecture sets the map, bands set ranges, cycles execute decisions with budgets and approvals.

1. Add job architectures (roles/levels).
2. Set compensation bands aligned to those jobs/levels.
3. Add currencies if you operate globally.
4. Create a compensation cycle with budgets.
5. Assign admins and run the cycle.

3) Objects & terms

These terms come directly from the official Compensation article titles and help you navigate the feature set.

• Compensation bands: structured ranges for roles/levels.
• Compensation cycles: the periodic review workflow.
• Job architectures: the role/level framework used for comp.
• Budgets: cycle budget types used to control spend.
• Currencies: multi-currency support for planning.
• Compensation admins: admins added to manage compensation features.

5) Core jobs-to-be-done

Use these jobs as your implementation plan for the first compensation cycle.

• Add job architectures for Deel Compensation.
• Set up compensation bands.
• Create and manage compensation cycles.
• Choose budget types for the cycle.
• Add currencies for global comp planning.
• Add admins to Compensation (control who manages cycles).

6) Happy path workflow #1 — Set up the foundation

Use this when you’re preparing for your first cycle and want the structure in place before inviting stakeholders.

1. Define your job architecture (levels, roles, families) in your internal comp doc.
2. Configure job architectures in Deel Compensation.
3. Create compensation bands aligned to each level/role.
4. Add currencies you plan to use for the cycle.
5. Add Compensation admins (small set of owners).
6. Run a spot-check: sample worker mapped to job/level and correct band.

8) Decision points (A/B)

These decisions determine complexity and adoption speed.

9) Common mistakes + guardrails

Most issues come from weak structure or too many admins. Keep it disciplined.

• Mistake: starting cycles before job architecture → Avoid: set architecture and bands first.
• Mistake: inconsistent leveling → Avoid: define leveling rules internally.
• Mistake: too many admins → Avoid: keep a small owner group.
• Mistake: unclear budgets → Avoid: align on budget types and constraints up front.
• Mistake: currency confusion → Avoid: document FX assumptions and currency usage.

2) Mental model (intake → sourcing → selection)

Keep your mental model simple: define the role clearly, decide how candidates are sourced, then run a consistent selection process. Complexity kills speed and quality for early adoption.

1. Role intake: requirements, must-haves, timeline.
2. Candidate sourcing: where candidates come from (Deel Talent/partners/other).
3. Screening and interviews: consistent stages.
4. Offer and handoff: move to onboarding/People.

3) Objects & terms

These terms come from the official Talent Management section list.

• Deel Talent (for Clients): client-facing overview context.
• Deel Talent (for Talent Partners): partner-facing overview context.
• Hiring with Deel Talent: practical hiring guidance entry point.
• FAQ pages: reference for edge cases and clarifications.

5) Core jobs-to-be-done

Use these jobs to plan your first “real” role you hire through this path.

• Read the client overview and align stakeholders on scope.
• Define hiring intake template (requirements, budget, timeline).
• Run one hiring flow end-to-end.
• Decide whether to use ATS integrations vs manual tracking.
• Establish partner collaboration rules (if using partners).
• Define handoff steps from “hired” to People onboarding.

6) Happy path workflow #1 — Hire with Deel Talent (minimal)

Use this as a simple blueprint for one role so you can iterate quickly.

1. Confirm the role requirements and hiring timeline.
2. Review the Deel Talent client overview so stakeholders know what to expect.
3. Decide sourcing method and ownership (HR vs manager vs partner).
4. Set 2–4 pipeline stages (screen → interview → decision).
5. Run candidate screening with consistent criteria.
6. Make decision and document rationale.
7. Handoff the hire to People onboarding steps.

8) Decision points (A/B)

These decisions determine speed and consistency.

9) Common mistakes + guardrails

Hiring breaks down when speed and ownership are unclear.

• Mistake: vague role intake → Avoid: define must-haves and timeline.
• Mistake: too many stages early → Avoid: keep pipeline lean.
• Mistake: slow feedback → Avoid: set response SLAs.
• Mistake: no handoff to onboarding → Avoid: define “hired → People” steps.
• Mistake: unclear partner boundaries → Avoid: document responsibilities.

2) Mental model (inputs → scenarios → decisions)

Treat planning like a loop: gather inputs, build scenarios, choose a plan, and review outcomes. Start small—one department or one quarter.

1. Inputs: current workforce data, open roles, budget constraints.
2. Scenarios: hiring, backfill, re-org, or hiring freeze.
3. Decision: approve plan and owners.
4. Review: compare plan vs actual and iterate.

3) Objects & terms

The official section explicitly connects Workforce Planning with Engage, so align terminology across both.

• Workforce planning: deciding headcount and structure over time.
• Engage connection: planning is referenced as “with Engage”.
• Workforce data inputs: typically come from People directory/structure.
• Scenarios: alternative plans compared for decision-making.

5) Core jobs-to-be-done

Use these jobs as your first implementation backlog.

• Define scope (which orgs/teams, which timeframe).
• Define owners (HR, finance, business lead).
• Collect baseline workforce inputs from People/structure.
• Create 2–3 scenarios and compare impacts.
• Turn the approved plan into hiring/onboarding actions.
• Review plan vs actual monthly and update.

6) Happy path workflow #1 — Run a mini quarterly plan

Use this when you’re adopting the feature and want a safe first win.

1. Select one department and one quarter as your pilot scope.
2. Gather current headcount and structure inputs from People.
3. Define constraints (budget, critical roles, timelines).
4. Create two scenarios: baseline vs growth (or baseline vs freeze).
5. Review scenarios with stakeholders and pick one plan.
6. Translate the plan into actions: roles to hire, backfills, timing.
7. Set a monthly review checkpoint.

8) Decision points (A/B)

These choices determine adoption speed and accuracy.

9) Common mistakes + guardrails

Planning fails when assumptions are hidden and no one owns follow-through.

• Mistake: unclear scope → Avoid: define team and timeframe precisely.
• Mistake: no single owner → Avoid: name an accountable lead.
• Mistake: too many scenarios → Avoid: keep to 2–3.
• Mistake: no plan-vs-actual review → Avoid: monthly checkpoint.
• Mistake: People data not maintained → Avoid: assign a People data owner.

2) Mental model (dashboard vs report)

Dashboards are for ongoing monitoring; reports are for answering a specific question and sharing/exporting. Start with one dashboard, then add a report per recurring question.

1. Pick a recurring question (e.g., “What’s our workforce status?”).
2. Create a dashboard view for quick monitoring.
3. Create a detailed report for drill-down.
4. Save and share with controlled access.

3) Objects & terms

These terms map directly to the Reports articles.

• Analytics 2.0: reporting capability referenced in docs.
• Dashboard: saved monitoring view.
• Report: saved query/view that can be shared.
• Custom report: report you design and share.
• Total Payroll Summary Report: a specific downloadable summary.

5) Core jobs-to-be-done

These align with the official reporting articles and what most teams need early.

• Understand Analytics 2.0 basics.
• Create and save dashboards.
• Create and save reports.
• Decide what kinds of reports you need.
• Create and share a custom report.
• View and download a Total Payroll Summary Report.

6) Happy path workflow #1 — Build a first dashboard

Use this when you want a single place to monitor key HR/ops signals weekly.

1. Open Analytics 2.0 and decide the dashboard purpose (ops, payroll, people).
2. Pick 3–5 metrics that answer your weekly questions.
3. Create the dashboard and arrange components for quick scanning.
4. Save the dashboard with a clear name and owner.
5. Share with the smallest necessary audience.
6. Review in your weekly meeting and refine.

8) Decision points (A/B)

These choices affect trust and maintenance effort.

9) Common mistakes + guardrails

Reporting pain usually comes from unclear definitions and report sprawl.

• Mistake: unclear metric definitions → Avoid: define terms in the report description.
• Mistake: too many similar dashboards → Avoid: assign owners and archive duplicates.
• Mistake: sharing sensitive data widely → Avoid: least-privilege sharing and role checks.
• Mistake: no validation → Avoid: spot-check before publishing.
• Mistake: forgetting payroll summary needs → Avoid: standardize how you download and store summaries.

2) Mental model (systems + sync rules)

Every integration needs a “source of truth” decision. Decide where each field is mastered, then define the sync direction and cadence.

1. Pick your master system for worker core data.
2. Decide what Deel should push vs pull.
3. Define who owns failures and reconciliation.
4. Roll out to a pilot group before full org.

3) Objects & terms (integration categories)

These categories are explicitly listed under Integrations & API in the official navigation.

• HRIS Integrations
• Applicant Tracking System (ATS) Integrations
• SSO Integrations
• SCIM Integrations
• SFTP Integrations
• User Management Integrations
• Accounting Integrations
• Deel API

5) Core jobs-to-be-done

Use these jobs as your integration implementation plan.

• Choose an integration category (HRIS, ATS, SSO, etc.).
• Define what data should sync and in what direction.
• Set up identity (SSO/SCIM) for access scaling (if applicable).
• Connect ATS if hiring pipeline needs syncing.
• Use SFTP for file-based workflows if required.
• Use Deel API for custom needs.

6) Happy path workflow #1 — Connect an HRIS integration (pilot)

Use this when you want worker data to be consistent across systems.

1. Select the HRIS integration path from Integrations & API.
2. Define source-of-truth for worker fields (name, email, manager, etc.).
3. Confirm Roles & Permissions so the right admins can configure the integration.
4. Pilot with a small worker group.
5. Validate: workers match in both systems, and manager relationships are correct.
6. Document the sync rules and what to do when mismatches happen.
7. Scale to the rest of the org.

8) Decision points (A/B)

These decisions define your integration architecture.

9) Common mistakes + guardrails

Integration mistakes are expensive because they create silent data drift.

• Mistake: integrating before data cleanup → Avoid: fix duplicates and structure first.
• Mistake: unclear source of truth → Avoid: define field ownership in writing.
• Mistake: broad admin access for setup → Avoid: least privilege and time-boxed access.
• Mistake: skipping pilot → Avoid: pilot a small group.
• Mistake: no failure ownership → Avoid: define who monitors and fixes sync issues.