Skip to content

Project Planning

Anushka Wijesundara edited this page Oct 19, 2026 · 2 revisions

Project planning

Use Projects → your project. The sidebar follows the standard ServiceOps navigation and keeps the active project visible. The horizontal tabs offer the same destinations.

Backlog

Backlog opens the selected sprint or unassigned work; Grouped backlog shows active/planned sprints and the backlog together. Expand a section to inspect its work. Search by key or summary, filter by person, version or epic, or choose a quick filter: mine, unassigned, flagged, overdue or unestimated. Filters combine rather than replacing each other.

Assignee avatars provide shortcuts. Insights totals the complete filtered result, including work outside the current page. Change a row's status or story points and choose Save. Bulk assignment and ranking preserve the originating sprint, page and filters. View settings saves your own choices for points, people, versions, epics, priority and compact rows; it does not change another user's view.

Grouped backlog

Timeline

Timeline shows nested work, dates and visible blocking dependencies. Expand a parent to drill down through recursive subtasks. Search/status/person filters retain the ancestors of matching work. Choose weeks, months or years, an anchor date, Previous/Next or Today. Cross-project planning offers a project scope selector. Copy view link shares the selected view; recipients still need access. Full screen and an internally scrollable chart are available.

Missing parent dates are derived from children for display only, marked Derived. This does not save dates. Warnings list conflicting finish-to-start dependencies and missing due dates; the list remains available when lines are outside the chart.

Timeline and shared navigation

Propose, review, apply

  1. Open the date disclosure beneath a work item, enter dates and choose Review date changes; or open Auto-schedule and choose a start date, working hours and resource options.
  2. A persistent, private draft records the proposed changes. No work dates change yet. Saved drafts are available from the timeline.
  3. Review the before/after dates, select changes and apply. Unchecked changes are left untouched; the draft is consumed after any successful application. Create another draft for further work. Discard removes an unapplied draft.

Drafts belong to their creator and tenant. Every project is checked again before stored details are shown. Application rechecks current access and the complete planning fingerprint while holding project/draft locks. Changes to work, assignments, estimates, dependencies or access make an old draft stale; create a fresh draft. Duplicate concurrent application cannot apply twice. Partial automatic plans cannot omit prerequisite dates or push a prerequisite past an unchanged successor.

Auto-scheduling uses finish-to-start dependencies, existing working-day spans or remaining/original estimates. Missing estimates default to one working day. Weekends are excluded unless selected. Each assigned person is reserved for the full duration when overlap avoidance is enabled; unassigned work has no person constraint. Completed and read-only work stays fixed. Visible external prerequisites constrain dates; a missing prerequisite due date requires correction first. Dependency cycles are rejected. Parent dates roll up from children in the proposal.

This is a bounded planning aid, not an employee availability/leave calendar or an optimal capacity solver. Limits: 50 visible projects, 500 work items, 2,000 dependency edges, 10,000 expanded leaf dependencies, 366 working days per work item, five-year scheduling horizon and 50 pending drafts per person. Narrow the scope when a limit is reached. Supported date years are 1900–2200. Hidden projects and dependencies are never exposed.

Calendar, goals and team

Calendar displays work start/due dates and goal target milestones by month. Event links open the underlying work.

Goals stores outcomes, target dates, description and state. Add linked work through the searchable selector. Progress counts completed linked items, and overdue open outcomes are highlighted. Links must belong to the same project; project editors manage goals, viewers inspect them.

Team shows project membership, roles, assigned open work, estimates, remaining time, unestimated items and release milestones. Shared assignments count toward each assigned person. These are recorded work totals, not contractual capacity or employee availability.

Goals

API

All interfaces require the existing project feature, acting user, tenant checks and projects:read or projects:write scope. Web writes use CSRF-protected forms. See the deployed /api/v1/openapi.json.

Path below /api/v1 Methods Purpose
/project-planning/timeline GET Visible planning context and chart data; repeat project=KEY to scope
/project-planning/drafts GET, POST Own visible drafts; create manual or automatic proposals
/project-planning/drafts/{id} GET, DELETE Inspect or discard own unapplied draft
/project-planning/drafts/{id}/apply POST Apply selected item_ids after validation
/projects/{key}/goals GET, POST List/create project outcomes
/projects/{key}/goals/{id} PATCH Update an outcome
/projects/{key}/view-preferences GET, PUT Personal display settings
/projects/{key}/planning-calendar GET Calendar data
/projects/{key}/planning-team GET Membership and recorded workload

Creation requests for drafts and goals require Idempotency-Key. Manual draft JSON uses projects, name, mode: manual and changes: {"item-id": {"start": "YYYY-MM-DD", "due": "YYYY-MM-DD"}}. Automatic drafts use projects, name, start, optional hours, weekends and reserve_people. Null dates clear the corresponding field. Apply uses {"item_ids": [id, ...]}. View preferences accept boolean show_points, show_assignees, show_versions, show_epics, show_priority and compact.

Delivery evidence · Sprint lifecycle · Remaining Premium programme

Saved plans, structure and program board

Open Projects → Plans → Create plan and select project sources. The plan sidebar keeps ServiceOps navigation. Timeline, Structure, Program board, Teams, Releases and Dependencies share that scope.

  • Structure: add a Portfolio, Program, Initiative or custom named level, optionally beneath another level, and link visible work keys. Expand the combined tree. Issue completion and story-point progress are separate; recorded parent estimates are included, so avoid estimating the same work twice.
  • Teams: choose members, hours or points, and capacity per iteration. Missing estimates remain visible; hours and points are never converted implicitly.
  • Program board: drag a card into a team/iteration, or open its Schedule form. Allocation changes the proposal, not work dates. Date review sequences dependencies within the chosen iteration and rejects work that cannot fit its duration; move it to a later iteration or increase the iteration length. Auto-schedule fits estimated leaf work to dependencies and iteration capacity. Unknown or unplaceable work blocks automatic allocation with an explanation.
  • Scenarios: save and restore plan settings/allocations. Restore changes the plan only. Review changes creates a persistent date draft; apply the selected rows to update actual work.
  • Releases and Dependencies report show project releases and visible blockers across the selected scope.

Plan commands require the current revision. Concurrent stale commands receive HTTP 409. Plan editing requires ownership or tenant administration plus edit access to every source project. Limits: 100 plans/tenant, 50 teams/plan, 500 structure nodes/plan, 52 iterations, 20 saved views; scheduling retains the timeline bounds above.

Automation

Open Projects → Automation, choose project sources and configure When → conditions → related-work branch → actions. Select a component in the left flow to edit it. Conditions can compare a literal or a trigger field. Branches support the trigger, parent, children, descendants or linked work. Actions transition status (including copying the trigger category), edit priority/flag/title or add comments.

Preview shows targets without changing them. Live created/updated/transitioned events execute as the rule owner, with current project permissions. A rule failure rolls back that rule's actions while preserving the initiating edit; the audit reports blocked/failed outcomes. Automation cannot recursively trigger itself. Bounds: 100 targets/rule, 100 rules/tenant, 10 actions/rule, 1,000 actions/event. Execution is synchronous; external HTTP actions and automatic retries are not supported. Disable a rule to stop future execution.

Forms, pages, reports and shortcuts

Forms are typed intake definitions managed by project administrators. Add fields visually (text, paragraph, integer, number, date, choice, multiple choice or boolean); JSON is available for advanced editing. An enabled form creates a real work item for an editor. Open Submitted form on the item to read the immutable question/answer snapshot; later edits to the form do not rewrite it. Disabled forms stop new submissions.

Pages store revision-checked Markdown and render it through the existing sanitized project renderer. Reports offers actual UTC daily creation/resolution counts and median creation-to-resolution lead time over 7/30/90/365 days. This complements sprint burndown/velocity; it is not a control chart. Shortcuts supports administrator-managed internal paths or HTTPS links without embedded credentials.

The matching API is documented in /api/v1/openapi.json: /project-plans, /project-automation, /projects/<key>/content/<view> and form submission. Reads require projects:read; writes require projects:write and the acting user's project role. Create/submit calls require Idempotency-Key. Work-item detail JSON includes form_responses.

Installation administration

Removed in 1.113.57 to keep ServiceOps minimal: release tracks, the IP allowlist, admin insights and sandboxes no longer exist. Restrict client addresses at the ingress or Cloudflare Access instead.

Clone this wiki locally