Work management

Every project has a plan: a tree of work items that Flow Relay schedules for you. You edit it in the project workspace (grid, board and timeline views), from the API, from an AI agent through MCP or from VS Code. Every surface goes through the same scheduler, so a date moved in one place is the date every other place shows.

Numbers are computed, never generated: dates, slack, the critical path and progress come from a deterministic scheduler. AI features describe the plan in words and never write a number into it.

Coming from MS Project or a spreadsheet? Import the plan instead of rebuilding it. Starting from nothing? Let AI draft the plan from a brief or a meeting.

A work item is a task or a milestone (a task with zero duration). An item with children becomes a summary: its dates, work and progress roll up from the items below it and are not edited directly.

Each item has:

• a key such as FR-12 – the project key plus a number. Numbers are never reused, not even after a deletion, so a key always points at the same item.
• a status: backlog, todo, in_progress, in_review, done or cancelled. blocked is a separate flag, so a blocked item keeps its status.
• a priority from 0 (lowest) to 4 (urgent).
• a duration, progress (0-100) and optional deadline, plus the assignees.

The project key is set in the project settings (2 to 10 characters, letters and digits, starting with a letter). Changing it gives every item a new key and keeps the old key as an alias, so branches, commits and links written before the change still find the item. A key cannot be the same as the key of a Jira project mirrored in the same organization, or commit messages would point at two items.

A plan has a time zone. Every date in the plan is a wall-clock time in that zone – 2026-10-02T17:00 means five in the afternoon where the project works, for everyone who reads it, wherever they are. The API returns the zone next to the dates as timezone; the web app names it when it differs from yours.

Durations are written the way project managers write them:

Working time comes from the plan calendar. The default is the classic standard calendar: Monday to Friday, 08:00-12:00 and 13:00-17:00. In Plan settings (the gear in the workspace toolbar) a manager can create a calendar with its own hours, breaks, holidays and closures and switch the plan to it; organization calendars are shared by every project of the organization. The same panel sets how long a day, a week and a month are, the plan time zone, the project start, the target finish and the status date.

Items can depend on each other with the four classic link types – finish-to-start (the default), start-to-start, finish-to-finish and start-to-finish – with a positive lag or a negative one (a lead), in working time, elapsed time or as a percentage of the predecessor.

When anything changes the scheduler recomputes the whole plan: the earliest dates each item can take, how much slack it has and which items are critical (no slack: a delay there delays the finish). Each item can explain its own dates – the link, constraint or actual date that drives them – in the Why this date section of the item panel.

A link that would create a loop is refused and the reply names the items in the loop.

Sprints and cycles are iterations: a name, optional start and end dates, a goal and a state (planned, active or closed). Managers create them in Plan settings > Iterations; an item joins one from the Iteration field of the item panel. On the board, the iteration picker shows only the items of one iteration together with its burndown: how many of its items were still open on each day.

Jira sprints and Linear cycles of a mirrored tracker arrive as iterations too. They follow the tracker and cannot be edited in Flow Relay.

A team that lives in Jira, Linear, GitHub Issues, GitLab, Azure Boards, Asana, ClickUp, monday.com or Shortcut does not have to copy its tickets. When the project is connected to a Jira project, a Linear team, a repository, an Asana project, a ClickUp space, a monday.com board or a Shortcut team, a manager turns on Plan settings > Trackers for it (Team plan and above) and the open issues, the issues updated in the last 30 days and the epics appear in the plan – up to 2,000 per tracker.

The tracker stays the source of truth for what it owns and Flow Relay never writes back:

Statuses map by category, so a custom Jira workflow still lands on To do, In progress, Done or Cancelled. A mirrored item keeps its Flow Relay key and also answers to the tracker key (PAY-123, acme/web#42, AB#321) everywhere: in commit messages, in the API and in MCP. A "blocks" link between two mirrored issues becomes a dependency suggestion (Jira, Linear, Asana and Azure Boards report them). An issue deleted in the tracker leaves the plan; one that drops out of scope stays with its last known values.

How each tracker maps:

The mirror refreshes with every sync of the connection (every 6 hours and Sync now) and right after a change arrives from the tracker's webhook (Jira, Linear, GitHub, Asana, ClickUp and monday.com; the others wait for the next sync). A sync error shows under the tracker in Plan settings > Trackers.

Import > Draft with AI writes a first plan from a brief ("launch the self-serve billing page by November...") or from a meeting transcript in the project's scope. The draft has phases, tasks, estimated durations and dependencies and never assigns anyone. It opens in the same preview as an import: nothing is created until you apply it, and you can apply it on top of the current plan or instead of it. A draft costs 10 credits; transcripts never go to China-hosted models.

Roles are set in Plan settings > People. A role changes what someone can do in the plan, never who can see the project: access still comes from the project teams. Managers can also let contributors change dates, durations and dependencies with Contributors can change the schedule (off by default).

An assignment says how much of a person's time a task takes: units (100% is full time, 50% half) and work (the hours of effort). Flow Relay keeps the MS Project rule Work = Duration x Units true on every task, and the task type decides what moves when you change one of the three:

With effort driven on, adding a person to a task keeps its total work and shares it, so the task gets shorter. Imported plans keep the work MS Project computed.

Each person in an organization is a resource with an availability (100% by default, 50% for someone half time on the project) and a working week – the plan calendar, or a pattern such as Monday to Thursday or mornings only. Organization admins set both in Plan settings > Resources; in a personal project the owner does. The public holidays of the plan calendar apply under every personal week.

Days off belong to the person: each member adds them in Settings > Days off, or imports the out-of-office entries of their own Google Calendar or Outlook. Plans and the workload see them only as unavailable days, never with a reason, and the import keeps only the dates.

In the calendar editor of Plan settings, Public holidays fills a calendar with the public holidays of a country (Italy with the patron day of a city, Germany, France, Spain, the United Kingdom, the United States, the Netherlands), movable feasts such as Easter Monday included, for up to five years. Import .ics adds the all-day events of a calendar file, such as a company closure calendar.

The People view of a plan shows each person's planned hours day by day against the time they are available, with a table of the same numbers and the items behind every cell. Work the same person has in other projects appears as a single figure, never as items. Project managers see everyone; in an organization only once the Workload for managers policy is in force (see People data and privacy). Everyone else sees their own row.

Like the Team Planner of MS Project, the view is also where managers rebalance work: open a person to see the items behind their hours, pick Move to to hand an item to someone else (the units and work go with it) or assign the items listed under Unassigned work.

Level resolves overallocations the way MS Project does: it finds the first day a person is booked beyond their availability and delays the least important task on it, then repeats. Importance is the leveling priority (0 to 1000, 1000 means never move), then less slack, then the earlier start, then the item number, so the same plan always levels the same way. You see every delay before applying it, you can keep the finish date by leveling only within slack, and Clear leveling removes every delay. Leveling moves tasks; it never reassigns people.

Timesheet in the sidebar is a weekly grid of the hours you worked, per item. Your personal projects are always there; an organization appears once it turns Time tracking on. Enter time as 1:30, 1.5 or 90m, start a timer on an item (it keeps running in your browser while you work) and export the week as CSV.

Fill from my linked work splits the hours you enter for a day across the items you have linked activity on that day, in proportion to that activity. The suggestion is computed for you and shown to nobody else.

When the organization also turns Timesheet approval on, you submit each week and an admin approves it or sends it back with a comment; an approved week can no longer change. Project managers see the hours logged on their own projects, in People > Logged time – with approval, only the weeks that were submitted.

My work opens with your week: the hours planned for you each day against your available time, and the items that make them up. Review my week writes a private summary of what you finished, what is in progress, what is blocked and what comes next, from your own items and their linked activity. It costs 2 credits from your own plan and only you can read it.

On plans that include costs (Business and above) project managers can price a plan the way MS Project does.

• Rates. In Plan settings > Costs set an hourly rate per person, equipment or placeholder, and a price per unit for a material. A rate can change from a date: work done before that day keeps the old rate. Rates by role give a person with that role label and no rate of their own the rate of their role. A cost per use is charged once when a resource starts on a task.
• Resources. Organization admins add placeholders (a role still to fill), equipment, materials and cost resources to the pool. A cost resource has no rate: the amount is typed on each assignment.
• Fixed cost and budget. Each item can carry a fixed cost that accrues at its start, at its end or spread over the task, and a budget. The plan has a budget and a currency, shared by the whole organization.
• Where actual cost comes from. When people log hours the actual cost is those hours at the rate in force each day (only approved weeks when the organization approves timesheets); otherwise it follows each item's progress.

Rates and costs are visible to project managers only, never reach a prompt and are never shown on an item to anyone else.

A baseline saves the dates and the cost of every item at one moment; the plan keeps up to 11. Interim plans save dates only, like MS Project's Start1 to Start10. With a baseline that has costs, Reports > Cost shows the earned value figures at the status date: planned value, earned value, actual cost, schedule and cost variance, SPI, CPI, TCPI and the three estimates at completion, with the S-curve of baseline against current plan. Every figure comes from the scheduler, never from a model.

Set a status date in Plan settings to measure at a fixed day. On the timeline, Progress line joins the point each item has reached at the status date: left of the line is behind, right of it is ahead.

The Reports view has seven tabs:

Reports count items, never activity or people: the flow shows how many items sit in each status and never who moved them. Tables download as CSV and Print gives a clean page (A4 or Letter, the browser decides) with legends and the time scale. Project managers can also ask for a report by email every week or month: it lists the summary, the next milestones, what is late and the cost, in the morning of their own time zone.

Plan review on the project page writes a status report for the plan: progress, concerns, the outlook of each upcoming milestone, suggested register entries and next steps. Every number, date and index in it comes from the plan facts the scheduler computed; the model only writes the narrative around them and the last 14 days of linked activity. It costs 5 credits. Add to register turns a suggested risk into an entry. Like every AI text in Flow Relay it describes the work and never the people doing it.

The Register view keeps risks, assumptions, issues, decisions and dependencies. Risks and issues are scored as probability times impact (1 to 5 each) and the matrix counts the open risks. An entry has an owner, a due date, a response and an optional linked item; an owner is notified when an entry is assigned to them. Managers, the author and the owner edit an entry. Log decision on a handoff copies one of its decisions into the register as a closed decision.

A task can pause and resume: in the item panel, Pauses lists how far into the task each pause starts and how long it lasts. The task keeps its duration and finishes later, the timeline draws it in parts, and the workload skips the paused days. MS Project exports of a split task import as one continuous task.

The Calendar view lays the plan out by month, with non-working days shaded and milestones marked. The Network view draws the dependencies left to right as boxes and arrows, critical items in red; it is read-only and shows up to 300 items.

Forecast (Business plan) says how likely each finish date is, instead of giving one date as if it were certain. It simulates the plan thousands of times and reports the date by which half, four out of five and nineteen out of twenty of the runs are done, for the project and for every open milestone, with the chance of meeting the target finish or a milestone's deadline and the items most often on the critical path.

• From the durations of the plan. Each open task takes a little less or more than its planned duration, drawn from a triangular distribution: low uncertainty is 10% under and 25% over, medium 15% and 50%, high 20% and 100%. Tasks marked as an estimate (2w?) vary one step wider. Finished, cancelled and manually dated work does not vary. The same plan version always gives the same forecast.
• From how fast the team finishes. The open tasks are simulated against the number of items finished in each of the last twelve weeks. It needs at least four weeks of history with something finished, and answers when the team gets through the backlog at its recent pace.
• The four-out-of-five date is the one to promise; the median is the one to expect and will be missed half of the time. A forecast is a statement about the plan as it is: change the plan and run it again. Each run is kept, so the plan review can quote it and forecasts can be checked against what actually finished.

A scenario is a list of changes tried on a copy of the plan and compared with it: the finish of the project and of each milestone, how many items move and what becomes critical. Changes are a duration, a delay to a start, a cancellation or a link. Nothing changes in the plan until a project manager applies the scenario, and then it goes in as one batch that the change history records and can undo.

• Ask what if. Write the question in words (for example, what if the payment integration takes three weeks longer?). The model only turns it into changes to the work, using the keys of the plan; the scheduler computes every date. What it cannot express is listed as left out. It costs 5 credits.
• Build one by hand. Pick an item and a change.
• A saved scenario is compared again with today's plan whenever it is opened, and says when the plan changed since it was saved.

Flow shows how the work of a team moves: items finished per week, the time from start to finish, how many items are in progress and how long the oldest have been. Under it, Delivery estimates from the build, deploy and merge events of the connected tools how often the project deploys, how long a merged change takes to reach a deployment, the share of deployments that fail, how fast a failure is followed by a success and how many successful deployments follow a failure within a day.

These are figures about a team and its work: they appear only for projects with at least five members, never per person, and in an organization only once an admin turned on the Flow and delivery metrics policy (announced to members 24 hours ahead like the other visibility policies). The delivery figures are indications: merges and deployments are matched by time, not by commit.

On the Business plan an organization gets a Portfolio, opened from the projects section of the organization page. It shows the projects you can open and nothing more: an admin sees every project, a member the ones of their teams.

• Projects. One row per project with its progress, forecast finish (and how many working days late or ahead of the baseline or the target it runs), next milestone and open risks. Open a row to see why its health is what it is. Filter by program or health, sort by the worst health or by the forecast, and group by program.
• Health. Every night Flow Relay gives each project a verdict: on track, at risk or off track. It is the worst of four checks, each shown in the row: schedule (slip against the baseline, or the target finish when there is no baseline, and the share of open items that are overdue), cost (the cost performance index and the forecast against the budget – project managers only), scope (items added since the baseline) and delivery (the latest build or deploy, an open incident, and items In progress with no linked activity for a while). A project manager can set the verdict by hand with Set health when the numbers miss something: the comment stays next to it, every change is recorded and the computed verdict remains visible.
• Programs. Organization admins group projects into programs and assign a project from its row. A program is a lens: it changes nothing about who sees what.
• Roadmap. The projects on one time scale, grouped by program: the forecast bar filled to the progress, the target finish, the baseline finish and the milestones. Projects that wait for another one are listed under the chart.
• Links between projects. In the item panel, Other projects lets a project manager make an item depend on an item of another project of the organization, with any of the four link types. The successor takes the dates of the predecessor as a floor, its dates say so in Why this date, and a change in the predecessor project reaches the dependent plan within a minute. Loops between projects are refused. Someone who cannot open the other project sees only the key of the item it waits for.
• Capacity. Planned work of open items against available hours by role and month, for the next 3 to 12 months. Work assigned to a placeholder is demand nobody holds yet. It needs the Workload for managers policy and is for organization admins; a role held by fewer than 3 people is folded into a shared row, and with fewer than 3 people in the pool nothing is shown, so the view never reveals one person's own load. What if a new project starts adds hours per role to the table without saving anything.
• Requests. Any member can propose a project. Admins score the request (value, alignment, effort and risk, 1 to 5) into a priority index – value counts double, plus alignment, over effort plus risk – and approve or decline it. Approving creates the project and tells the requester.
• Goals. Objectives with key results. A key result follows either its numbers (from a start value to a target, updated by check-ins) or the plans of the projects and items linked to it; an objective averages its key results. Progress is never typed in, and the pace note (ahead, on pace, behind) only compares progress with the share of the period already gone.
• Ask. A question about the portfolio, answered from the table of the Projects view for 2 credits. The numbers were computed from the plans; the model only reads them.

A custom field with a formula is computed for every item and cannot be edited: type the formula when you add the field (Business plan, Plan settings > Custom fields). It can read the built-in fields of an item (status, priority, percent, start, finish, deadline, duration_days, work_hours, slack_days, critical, overdue, days_late, fixed_cost, budget, outline and a few more) and any other custom field. A field of type yes or no turns into an indicator.

if(overdue and percent < 50, concat("Late by ", days_late, " days"), "On time")
days_between(start, deadline)
wbs("N.A.N", "WEB-")

Operators are + - * / %, comparisons, and, or and not. Functions are if, min, max, abs, round, floor, ceil, concat, len, upper, lower, contains, coalesce, is_empty, days_between, add_days and wbs. Dates are written as 2026-10-09. A formula that cannot be computed for an item (a missing date, a division by zero) shows nothing for it and never an error.

wbs("N.A.N", "WEB-") writes a WBS code from the outline position of the item: N is a number, A an uppercase letter and a a lowercase letter for that level, so the third subtask of the second task under phase 4 becomes WEB-4.B.3.

Plan settings > Recurring items (Team plan and above) turns routine work into items that appear on their own: a weekly report, a monthly review, a quarterly audit. Choose how often (every day, week, month or year, every N of them, on chosen weekdays or on a day of the month such as the last one), the first date, an optional end date, a duration and an assignee. Once a day Flow Relay creates the next item under the parent you chose with its start no earlier than that date and the date as its deadline. If the job was down for a while only the latest occurrence is created, not the whole backlog. The item is a normal one: the history shows who set up the routine, and pausing or removing the routine leaves the items already made.

An automation lets the plan react on its own (Team plan and above, Plan settings > Automations). Each rule has a trigger, optional conditions and up to five actions:

Conditions read the item (status, priority, percent complete, overdue, a custom field and so on) or, for an event, its source, type and title. Actions: set the status, the priority, the blocked flag or a custom field, assign the item to its creator or to the rule owner, add a comment, notify the assignees, the creator or the project managers, create an item, add a template or send a webhook. Texts accept {{key}}, {{title}} and the name of any field in the same double braces.

• A rule acts as the manager who last saved it. The change history names the automation, and changes an automation makes never start another automation, so rules cannot loop. A rule stops after 60 runs an hour and says so in its run list.
• Nothing is spent. Automations never call an AI model and never use credits.
• What happened is on record. Open Ran N times under a rule to see its runs of the last 30 days and which action failed and why.
• A scheduled rule skips done and cancelled items unless it filters on status, handles at most 200 items a run and sends one notification per person that lists the keys.

Save a whole plan (Plan settings > Templates) or one item with its subtasks (from its panel) as a template and add it again later, at the top level or under an item. A template keeps names, notes, durations, links, priorities and milestones; it never keeps people, dates, progress, costs or mirrored tracker items. In an organization the templates are shared by every project of the organization; on a personal project they are yours. Applying one is a single change that undo can revert.

The bookmark in the toolbar saves the current view: the grid, the board or the timeline together with its search, the status and person filters, the collapsed items and, on the timeline, the zoom and the overlays. A view is yours; a project manager can share one with everyone on the project. Filters by status (all, open or one status) and by person (everyone, you, unassigned or a member) work on the grid, the board and the timeline.

Attach up to 20 files of 25 MB each to an item from its panel. Files are private: they open through short-lived links after Flow Relay checks that you can see the project, and each project has a storage allowance by plan (50 MB on Free, 500 MB on Starter, 5 GB on Team, 20 GB on Business). Programs and scripts (.exe, .bat and similar) cannot be attached. Deleting a file removes it for good.

Plan settings > Webhooks (Team plan and above, project managers) tells another system when the plan changes: an item is created, changes status, is assigned, is blocked or unblocked or is deleted, or a rule sends it. Send to any HTTPS address as signed JSON, to a Slack incoming webhook or to a Microsoft Teams workflow.

{
  "id": "f0c1…",
  "event": "item.status_changed",
  "created_at": "2026-10-09T15:00:00.000Z",
  "project": { "id": "3fa85f64-…", "key": "FR", "name": "Billing", "timezone": "Europe/Rome" },
  "item": { "id": "…", "key": "FR-12", "title": "Payment webhook", "status": "done", "percent_complete": 100, "start": "2026-10-05T08:00", "finish": "2026-10-09T17:00", "deadline": null, "url": "https://www.flowrelay.it/…" },
  "change": { "from": "in_progress", "to": "done" }
}

A message names the item, its status and its dates and never a person. Every delivery carries X-FlowRelay-Event, X-FlowRelay-Delivery, X-FlowRelay-Timestamp and X-FlowRelay-Signature: sha256=<hex>, the HMAC-SHA256 of the timestamp, a dot and the raw body with the secret shown once when you create the webhook. Reject a timestamp older than five minutes. Flow Relay retries up to six times with growing pauses, gives up right away on a client error other than 408 and 429 and turns a webhook off after ten failed deliveries in a row or a 410 answer. The address is stored encrypted and never shown again.

Settings > Calendar feed creates a private link that lists the items assigned to you, with their dates, as an iCalendar feed for Google Calendar, Outlook or Apple Calendar (subscribe from a link). It shows the key, the name, the status and the project of each item and nothing else, only for projects you can still open. Anyone who holds the link can read that list, so remove it from the same page if it leaks. You can keep up to five links.

The work item endpoints use the same API key as every other endpoint and cost no credits. See the API reference for the full parameter list.

curl "https://www.flowrelay.it/api/v1/projects/3fa85f64-5717-4562-b3fc-2c963f66afa6/work-items" \
  -H "Authorization: Bearer fr_your_api_key" \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"title": "Move invoices to Paddle", "duration": "3d", "deadline": "2026-10-09", "assignee": "me"}'

• GET /my-work – the items assigned to you across every project.

• GET /projects/{id}/work-items – a project plan, filterable by status and assignee=me, paginated with cursor.

• GET /projects/{id}/work-items/{ref} – one item by key (FR-12) or id, with dependencies and linked evidence.

• POST /projects/{id}/work-items – create an item.

• PATCH /projects/{id}/work-items/{ref} – change status, progress, title, description, priority, the blocked flag, duration or deadline. Send ifVersion with the version you read to refuse the change when someone edited the item in the meantime.

• GET and POST /projects/{id}/work-items/{ref}/evidence – read the linked activity of an item or attach a link to it.

• GET /projects/{id}/suggestions and POST /projects/{id}/suggestions/{suggestionId} – list the pending suggestions and accept or dismiss one.

• GET and POST /time-entries – read the hours you logged and log time on an item or a project.

• GET /projects/{id}/evm – costs and earned value against a baseline (managers, plans with costs).

• GET and POST /projects/{id}/raid – read the risk register and add an entry.

• GET /portfolio?organization_id= – the projects of an organization with progress, forecast, risks and health (Business plan).

• GET /projects/{id}/forecast – simulate the plan and read the dates by which half, four out of five and nineteen out of twenty of the runs are done (Business plan).

• POST /projects/{id}/whatif – a what-if question in words, answered with the new finish dates and nothing saved (Business plan, 5 credits).

• GET /projects/{id}/automations – the automation rules of a project with a sentence for each and how they ran (Team plan and above).

• GET /projects/{id}/templates and POST /projects/{id}/templates/{templateId}/apply – list the saved templates and add one to the plan, at the top level or under the item named in parent (project managers).

• GET and POST /projects/{id}/approvals – read the change requests of an organization project and ask for a change to one item that a second person must approve (Business plan and above).

Every ref accepts the item key, a former project key, the tracker key of a mirrored item or the item id.

The MCP server exposes the same operations as eighteen tools: list_my_work, list_work_items, get_work_item, create_work_item, update_work_item, list_suggestions, link_evidence, list_raid, get_earned_value, get_portfolio, get_forecast, plan_whatif, list_automations, list_templates, apply_template, list_approvals, request_change and generate_plan_review. An agent can pick up the next item, move it to in progress, attach the pull request it opened and close the item when the pull request merges.

The VS Code extension adds a My Work view to the Flow Relay sidebar. Start Work Item creates a branch named after the item (fr-12-move-invoices-to-paddle) and moves the item to in progress; commits and pull requests on that branch are then linked to the item automatically (see Evidence linking). While the branch is checked out, the status bar shows the item and its status. Create Work Item from Selection turns the selected text into an item and notes the file and line it came from, Ask a What-if Question tries a question on a copy of the plan Add a Template to the Plan adds a saved template, and Show Change Requests and Request a Change to an Item read and file change requests.

Organization projects on the Business plan can require a second person to approve a change: anyone who may not edit the schedule can send a refused edit as a change request, and a project manager can require approval to replace or clear a baseline. Enterprise organizations define custom roles (who sees costs and restricted fields, who approves), share a read-only view of the plan through links and named guests, and control how long the change history is kept. See Governance and enterprise controls.

Every item keeps a trail: its history (who changed what, when), its linked activity and the handoffs and insights that cite that activity. Export trail in the item panel downloads the trail as Markdown or CSV – on a summary item it covers every item below it, which is the evidence pack for a release phase or an audit. The Plan summary card on the project page shows how many finished items have linked activity, so a plan that is only updated by hand stands out.

Flow Relay tells you when someone assigns you an item, mentions you in a comment or changes the status of an item you follow, when your items are due within a day or overdue, when linked activity suggests a status or evidence for your item, when an item of yours has been quiet for a while and when someone links an account to you. Notifications land in the inbox (the bell in the top bar) and, if you want, as push notifications and an hourly email digest. Quiet hours are on by default: from 19:00 to 08:00 and at weekends push and email wait, the inbox still updates. Change all of this in Settings > Notifications.

• 20,000 work items per project. Plans can lower the cap (the Free plan allows 200).
• 500 operations per batch in the web app; the API changes one item per request.
• Deleted items can be restored for 30 days, then they are removed for good.
• Automations: 10 rules per project on the Team plan, no cap on Business. Also per project: 50 recurring items, 10 webhooks and 100 templates per organization or person, and 20 files per item.
• Run logs are kept for 30 days and webhook deliveries for 14.