First-party app
Deputy

Deputy

Manage Deputy employees, timesheets, leave, areas and locations.

stable Human ResourcesCalendar & SchedulingProductivity

About

Deputy ships in the w6w first-party pack. It declares 18 actions, 2 health checks, and the host runs its code in a sandbox that never sees the credential.

App id
io.w6w.deputy
Version
0.1.0
Author
w6w
Licence
MIT
Categories
Human Resources · Calendar & Scheduling · Productivity

Overview

Deputy is workforce management software — rostering, time and attendance, and the employee records underneath both — and this app puts the daily loop of it behind a workflow: clock an employee on or off, write and read worked time, and keep employee records in step with whatever system pays or provisions them.

Timesheets are the centre of it. A workflow can start and end a shift against an area, write a timesheet from Unix timestamps (creating one, or updating a specific record), and then read the results back either directly or through a filtered, sorted, joined QUERY that pages past Deputy’s 500-record response cap — the documented way to pull a date range out of an install whose timesheet table is far larger than that. Employees round it out with the full loop, from creating and updating a record to listing, filtering and inspecting the fields a given install actually exposes, since custom fields are real columns here.

Everything else is the context those records point at: the areas (Deputy’s OperationalUnit) a shift is worked in, the locations (Deputy’s Company resource) they belong to, and the leave requests sitting against an employee. A permanent token keeps the connection simple: the whole app is built for one install at a time, using the same credential Deputy recommends for an internal system connection, and the health checks separate “this install is reachable” from “this credential is live” and from Deputy’s own regional platform status.

Build with Deputy

Three routes to the same 18 actions. The Workflow tab is generated from Deputy's own manifest and carries its real ids, so it is copy-pasteable; the Code and CLI examples are the same call for any action on any app, so every app-specific value in them is a blank you fill in.

Create employee

employee-create

Create an employee record. There is no Active control: Deputy's own default applies, and an inactive record is created by passing `{"Active": false}` through Additional fields. The reference also lists Company, Contact, Role and AllowAppraisal as required fields of an Employee, so an install that rejects the call may be asking for one of them.

Get employee fields

employee-fields

List the Employee fields this install exposes (names, types and associations) — what Search Employees and Create/Update Employee expect.

Get employee

employee-get

Get one employee record by its Deputy id.

List employees

employee-list

Every employee record this connection may see, in one response. Deputy caps a single response at 500 records — use Search Employees to page a larger table.

Search employees

employee-search

Filter, sort and page employees with Deputy's own QUERY body, expanding related objects inline where useful.

Update employee

employee-update

Update an employee's fields. Only the fields you fill in are sent, so this behaves like an edit rather than a replace — nothing else on the record is blanked.

List leave requests

leave-list

Every leave request this connection may see, in one response (Deputy caps a response at 500 records). Read `Status` as an integer lookup and `DateStart`/`DateEnd` as the date-time view of the same window as `Start`/`End`.

Get location

location-get

Get one Location (the `Company` resource) by its Deputy id. Note this is not the `/my/location/{id}` endpoint, which only ever answers for the token's own owner.

List locations

location-list

Every Location (the `Company` resource) this connection may see, with its short code, parent, and its workplace / payroll flags.

Who am I

me

Get the Deputy user this connection's permanent token belongs to.

Get area

operational-unit-get

Get one Area (OperationalUnit) by its Deputy id.

List areas

operational-unit-list

Every Area (Deputy's OperationalUnit) this connection may see, with its parent Location, parent Area and roster settings.

Create or update timesheet

timesheet-create-or-update

Write a timesheet from Unix timestamps — creating one when no Timesheet ID is given, and updating that timesheet when one is. This is Deputy's documented write path for worked time (clock-on/clock-off are separate actions).

Clock off (end timesheet)

timesheet-end

End an employee's timesheet and record the meal break taken in it — Deputy's clock-off call.

Get timesheet

timesheet-get

Get one timesheet by its Deputy id — including its approval, dispute and pay state.

List timesheets

timesheet-list

Every timesheet this connection may see, in one response. Deputy caps a response at 500 records — use Search Timesheets with a date range on any install of real size.

Search timesheets

timesheet-search

Filter, sort and page timesheets with Deputy's own QUERY body — the documented way to read a date range out of a install whose timesheet table is far larger than 500 rows.

Clock on (start timesheet)

timesheet-start

Start an employee's timesheet for a given area — Deputy's clock-on call.

A workflow step names the app and the action, and the editor fills in the connection when you pick one. This is the Step shape from the workflow spec, carrying Deputy's real ids.

{
  "manifestVersion": "2",
  "name": "deputy-example",
  "steps": [
    {
      "id": "employee-create",
      "uses": {
        "app": "io.w6w.deputy",
        "action": "employee-create",
        "connection": "conn_YOUR_CONNECTION_ID"
      },
      "with": {
        "firstName": "<firstName>",
        "lastName": "<lastName>"
      }
    }
  ]
}

Here are some of the things you can do

  • Create employee

    perform
    employee-create
  • Get employee fields

    read
    employee-fields
  • Get employee

    read
    employee-get
  • List employees

    read
    employee-list
  • Search employees

    search
    employee-search

+13 more actions available

Every app-specific value here is a blank you have to fill in. An app action is reached through the connection that authenticates it, so the address is a connection id, not the app id — and connections belong to your account, so a public page cannot know yours. Create one for Deputy, then fill in the three blanks: conn_YOUR_CONNECTION_ID, the action key, and the parameters that action declares. The call itself is real — the shape is transcribed from the studio's own snippet builder, which prints the same kind of blanks — but nothing in it is specific to Deputy. The Workflow tab is where this app's real ids are.

Install
npm install @w6w/sdk
yarn add @w6w/sdk
pnpm add @w6w/sdk
deno add npm:@w6w/sdk
Code
import { W6wClient, isActionRun } from "@w6w/sdk";

// Reads W6W_BASE_URL and W6W_TOKEN from the environment when omitted.
const client = new W6wClient();

const envelope = await client.run({
  urn: "conn_YOUR_CONNECTION_ID",
  action: "employee-create",
  payload: {
    firstName: "<value>",
    lastName: "<value>",
    // displayName: "<value>",
    // position: "<value>",
    // company: "<value>",
    // contact: "<value>",
    // role: "<value>",
    // startDate: "<value>",
    // fields: "<value>",
  },
});

if (isActionRun(envelope)) console.log(envelope.value);
Install the CLI
npm install -g @w6w/cli
CLI
w6w run conn_YOUR_CONNECTION_ID --action employee-create --payload '{"firstName":"<value>","lastName":"<value>"}'

Give an AI agent Deputy — without giving it Deputy's credentials. One MCP endpoint exposes every app, function and workflow the caller is entitled to, as tools it can discover and run. Access is granted per team while we onboard.

One tool call
{
  "name": "w6w_invoke",
  "arguments": {
    "ref": "app:io.w6w.deputy#employee-create",
    "input": {
      "firstName": "<firstName>",
      "lastName": "<lastName>"
    }
  }
}

Every tool names its target with a single ref. The app: form above doesn't name a connection at all — the host resolves which of the caller's Deputy connections to sign with, and refuses rather than guesses when the answer is ambiguous.

What the agent gets

Credentials it can't read

The token is attached host-side, at the moment of the call. It is never a tool argument, never in the model's context, and never in a transcript — so a prompt injection has nothing to exfiltrate.

A tool surface scoped to the caller

Tools are derived per end user from what that person has actually connected and is entitled to — not one shared bot identity carrying the union of everyone's access.

A durable workflow in one call

Multi-step work runs on the workflow engine and returns a run handle the agent can poll — retries, branching and state survive the conversation that started them.

Health-aware discovery

Deputy's declared health checks are on the surface too, so an agent can tell "the vendor is down" from "your credential expired" before it burns a retry on either.

The MCP surface is part of the hosted platform. Deputy itself is MIT, and the runtime that executes it is source-available (FSL).

Request MCP access

Health checks

Deputy declares its own checks, so its health is a property of the app rather than something the host guesses at.

dependency

Deputy install reachable

This connection's own Deputy install, probed unsigned against /api/v1/me. Deputy's documented auth-error envelope proves an install answered the call — no credential is sent, so a revoked token cannot make a live install look down.

service

Deputy platform status

Component status from status.deputy.com, scoped to Deputy's own regional API components (and their roll-up) — not the page's third-party group (Pusher, Twilio, Xero, Zuora, HelloSign) or Deputy's website, billing, sandbox and payroll components.