Sundial User Manual

A practical guide to shared project editing, task tracking, sprint planning, delivery forecasting, and diagram-based reporting. Updated against the source, specifications, and running application on 18 October 2026; sign-in and privacy guidance updated on 22 October 2026.

Open Sundial in a large desktop window and click Example to explore the demonstration project, team, and active sprint. If the active snapshot store is empty, Example also creates the demonstration reporting snapshots.

1. What Sundial does

Sundial is a project management application for organizing work, managing a team, running sprints, and forecasting delivery. The shared workspace and delivery simulator use the same work and staffing data. It helps project managers, technical leads, and contributors answer:

• What work belongs to the project, who owns it, and what is blocked or complete?
• What work belongs in the next sprint, and how does its remaining effort compare with available capacity?
• When can each initiative, epic, story, or task finish under the declared assumptions?
• How have scope, status, and forecast dates changed since an earlier checkpoint?
• What happens to delivery if a team member leaves or an additional person joins?

In the browser, you can edit Project and Team through forms, track work in Kanban, and plan Sprints. You can define workflow states and allowed transitions, write descriptions and acceptance criteria, add comments, set inherited priorities, record effort, and choose the order of work. For planning and review, you can use ten diagram views, capture reporting snapshots, import existing work, and export images. Project and Team are kept together in one native .sundial folder. Committed edits save automatically and can synchronize with other users opening that folder.

Sundial takes a privacy-first approach: it processes project data in your browser and keeps it in a project folder you choose, with browser storage for recovery. Your team can collaborate through a shared folder without uploading project information to an external collaboration service. Your organization's filesystem permissions control who can access that folder. Loading the application and looking up public holidays can still require network requests. The section on working together through a shared project folder explains storage, access, and backups in more detail.

The simulator uses estimates, recorded effort, dependencies, start constraints, deadlines, assignees, skills, working hours, availability overrides, weekends, and holidays. Kanban and Sprints update this model and share its task list.

You can create and manage a project entirely in Sundial. No external tracker is required. Sprint planning includes capacity, scope, completion, carryover, and historical boards. Sprint burndown, velocity, and cumulative-flow reports are not currently provided.

What a forecast means

Each ordinary forecast uses one set of declared assumptions. With the same model, calendars, and effective forecast start, Sundial produces the same schedule. The Monte Carlo tab repeatedly samples effort estimates to show completion-date distributions. Both use the same scheduling priorities and resource constraints; neither searches for an optimal plan. Their dates depend on credible inputs.

Disclaimer: Project timelines and delivery dates estimated by Sundial are indicative only and are not guarantees. The author accepts no responsibility for errors, omissions, delays, losses, or other consequences arising from these estimates or reliance on them, whether caused by software defects, inaccurate or incomplete data, planning assumptions, or any other cause. Review the estimates independently before using them to make commitments or decisions.

The approach follows the workflow-simulation method described in Stefano Tommesani's article on day-by-day project forecasting.

2. Quick start: explore the example

1. Open Sundial. For a local development build, use http://localhost:5173/.
2. Maximize the browser window. Detailed forms and diagrams need a large desktop workspace.
3. Click Example. Resolve any pending draft or replacement confirmation first. This loads the supplied Apollo project and team, plus an active example sprint and a planned next sprint. In an empty active reporting snapshot store, it also creates the demonstration July and August checkpoints.
4. Wait for Ready. Open Project to explore the hierarchy; click a work-item name to inspect its fields.
5. Open Team and choose a developer to review hours, skills, access, and calendars. Cancel any experimental draft you do not want to apply.
6. Open Kanban to see status columns, or Sprints to see the example sprint and developer capacity.
7. Open Diagrams. Charts use the full workspace. Close any work-item editor before reviewing the whole drawing. Review Delivery outlook, then WBS, GANTT, Sunburst, and Work tracker.
8. Choose a saved baseline in WBS over time or GANTT over time, leaving with at Now for a live comparison.
9. In Sunburst over time, select the July and August snapshots to compare them with Current. Review Scope and both Timeline and Scope presentations in Milestones, then try Team what-if. Use Reset to restore a staffing scenario after experimenting.

The example includes a work hierarchy, estimates, dependencies, team calendars, sprint membership, and comparison history. Live forecasts start from today unless the project has a later configured start. Example deadlines, the Public beta milestone, and sprint dates move with the date the example loads; historical checkpoints keep their saved dates. Your results can differ from the screenshots. An untouched demo is regenerated fresh on a later visit; use New or Open for your own project.

Figure 1. Project and Team are views of the same native project. The toolbar shows New, Open, Workflow settings, the project folder name, and Undo/Redo; the table includes inherited priority and navigation links.

3. Work together through a shared project folder

Several people can edit the same Sundial project through a shared folder. Work items, the team roster, calendars, and sprint plans stay in a native .sundial folder on your filesystem. Each person opens that folder in their own browser. Sundial saves committed edits automatically and exchanges them through the folder, so your team can work together without uploading critical project information to an external collaboration service.

Choose a mounted network share where everyone has read/write access. Your organization's filesystem permissions control access to the project. Sundial needs no central collaboration server or account database, and users can edit without taking an exclusive lock.

Start a shared project

1. Open Sundial in Chrome or Edge at the application's secure address; the local development address is http://localhost:5173/.
2. In Project, choose New, enter the project name and key, and select an empty parent folder where the new project should live. Grant the browser access to that folder when prompted. Sundial rejects folders that already contain files or subfolders.
3. Sundial creates a Project Name.sundial subfolder using your project name, without a UUID. This is the folder your colleagues must open.
4. Build the work hierarchy in Project and maintain the roster in Team. Use Apply or Apply changes to commit form drafts. Committed edits save automatically.
5. Make the folder available through your organization's shared filesystem, with read/write access for each collaborator.
6. Each colleague opens Sundial, chooses Project → Open or Team → Open, and selects that same .sundial folder. Opening it loads both Project and Team.
7. Check the displayed folder name and review any save or collaboration notices before starting work.

Separate copies on different machines will not exchange edits on their own. Each instance needs access to the same shared container, or a filesystem mechanism that delivers the complete folder contents between machines.

What happens when two people edit

Applied changes to different tasks or different fields normally merge automatically. For example, one person can revise Billing engine's estimate while another updates Bruno's availability. Sundial records each edit in its native history and picks up changes from the shared folder, normally checking every two seconds. The network share may take longer to deliver them.

Unapplied form drafts remain local. If another committed change makes a draft stale, Reload draft brings in the current document before you edit again. Review your intended changes and re-enter them against that version.

If two people independently change the same field, Sundial keeps both values and reports a collaboration issue. Their browsers can agree on the shared document while the team still needs to decide which value to use. This behavior is based on Automerge's handling of concurrent values.

Review a conflict

1. Open Diagrams, choose Show details in Delivery outlook, and expand warnings when diagnostics are present.
2. Read the entity, field, and alternative values. A ConcurrentFieldWrite means multiple values were written concurrently; ModifiedAfterDelete or ConcurrentDeleteRestore requires a decision about the item's deletion or restoration.
3. Find the affected task in Project, or developer/calendar in Team. Review the current committed value with the people involved.
4. After the remote changes have arrived, intentionally apply the agreed value. A subsequent write based on the observed alternatives resolves a field conflict; do not repeatedly alternate values without coordinating.
5. Recheck the reported issues and the forecast. Also correct dependency cycles, missing references, or other validation problems exposed by the merged edits.

Deleted tasks remain recoverable. If the team decides to restore one, use Deleted tasks → Restore in Project. Restoration keeps the original identity, so later edits and history continue to refer to the same item.

Privacy, backups, and interruptions

Sundial processes project data in the browser and stores it in your chosen project folder and browser recovery storage. Collaboration does not send it to a Sundial project backend. Network requests can still occur: you need to load the application, public-holiday lookups can contact a holiday service, and sign-in contacts Firebase Authentication and Google.

You can view projects without signing in. To make changes, choose Login at the top-right and then Continue with Google. Firebase Authentication manages the sign-in session; Google identifies the current editor. Project contents, filenames, work items, and estimates are not sent to either service. Signing in does not upload your project or grant access to shared files: your organization's filesystem permissions still control access.

Leave Remember me on this device unchecked for a browser-session sign-in, or check it to stay signed in on that device. Signing out keeps your open project and drafts. After signing in again, submit a pending change yourself; Sundial does not replay it automatically. Sundial normally refreshes your session automatically. If it cannot refresh before expiry, editing pauses while viewing remains available. Editing resumes after a successful refresh or sign-in; submit any rejected change again yourself. If browser storage is blocked, sign-in uses memory only and does not survive reload.

Figure 2. Unlock editing dialog with Continue with Google and the Remember me persistence choice.

Back up the entire .sundial folder, including its manifest, changes, snapshots, and readiness markers. Keep the internal files intact and retain the change history; copying a single file is not enough. Native startup snapshots help Sundial reopen efficiently. The dated checkpoints created with Snapshot are for reporting.

If a save fails, keep the browser session open, restore access to the share, and use the save notice's Retry action. Browser recovery restores the working native document after a crash or tab reopen. Sundial remembers its folder and resumes saving when browser permission allows. If the folder is not connected, a visible notice says that changes are not being saved to disk. Use Reconnect project folder and select the original .sundial folder. Sundial verifies its identity and merges recovered edits with the current disk history. Review Issues after reconnecting. A project using a newer unsupported format requires a compatible application version; do not try to repair it by editing internal files.

4. Find your way around the workspace

Main workspaces

The Project and Team toolbars have New, Open, the native project folder name, Undo, and Redo. Use the forms to edit and apply changes. Sundial saves them automatically; there are no separate Save buttons.

Application header

The header also links to the main website, this user manual, and the contact page. Contextual help icons beside workspaces and diagram controls open the relevant manual section in a new tab.

Diagrams, Delivery outlook, and Issues

Figure 3. Redesigned WBS using the expanded Example hierarchy, assignee labels, and Goal and Late goal borders.

Choose Diagrams, then the required diagram tab. Use a large window for viewing and captures. Hide details in Delivery outlook reduces the summary's height when more chart space is needed.

Delivery outlook puts the most delayed initiatives first and shows predicted delivery, declared deadline, and slip in calendar days. Its compact summary reports the largest forecast delay. On time means an initiative has a forecast finish on or before its deadline. Forecast through … shows the last day simulated; it does not mark tasks Done. An Unfinished label or a count of work items without a forecast means some work still has no delivery date. A missing estimate, blocked prerequisite, or unavailable capacity needs investigation even if other initiatives have dates.

Sundial refreshes the forecast when you apply a valid edit, so there is no Run button. While you enter a draft, the forecast still uses the committed model. Choose Show details in Delivery outlook to read errors, expand its warnings list, and resolve the reported issues before using the result. After a failed update, some diagrams keep the last successful result and show an error or stale-state indicator.

5. Open, create, and preserve a native project

One container for Project and Team

A .sundial project folder holds the native collaboration document and history for work items, developers, calendars, sprints, and related model data. Project and Team have separate editing screens, but their data and collaboration history are stored together. There is no pair of editable YAML files to maintain.

Use Chrome or Edge with directory access on a secure application origin or localhost. Open asks for a directory: select the actual .sundial container, not its parent, an individual change file, or a reporting snapshot. Opening through either Project or Team loads both halves.

Sundial cannot open or migrate legacy Project/Team YAML files through native Open. Reporting snapshots and optional import mappings are separate files with their own uses; neither is a native project folder.

Create a project

1. In Project, choose New and resolve any pending draft or replacement notice.
2. Enter Project name and Project key in Create project. The key uses 2 to 10 letters or digits and starts with a letter; Sundial normalizes it to uppercase. Choose it carefully because it locks once the first work item is allocated.
3. Choose Create, select an empty parent directory, and allow the browser to write there. The directory must contain no files or subfolders.
4. Sundial creates a Project Name.sundial subfolder with a new Project root and a reporting period beginning today. The currently available Team is used for the new project; review it before estimating capacity.
5. Click the root's name to edit it, then use the hierarchy controls to add work.
6. Open Team, review developers and calendars, and apply needed changes.
7. Verify save notices and a successful forecast. Retain the actual folder path for reopening or sharing.

Figure 4. Current Create project dialog with Project name and Project key fields.

Choosing New in Team replaces the current project's roster and calendars. It does not create a separately saved Team file.

Automatic saving and recovery

Applying Project or Team forms, changing Kanban status, editing sprint plans, and Undo/Redo commit native changes and trigger saving. There is no separate disk-save step for each tab. Plain Ctrl+S does not apply a draft or create a reporting checkpoint; use Apply to commit and Snapshot for a reporting baseline.

If a new, disconnected model first needs saving, Sundial may ask for a parent directory. A recovered project instead needs its original folder: use Reconnect project folder and select the matching .sundial container. Sundial checks its identity before merging browser edits with disk history. It tries to restore a remembered folder connection automatically when permission allows. Check save notices; the displayed folder name alone does not confirm that the latest edit reached disk.

Browser recovery restores the working native document after a crash or tab reopen. Sundial remembers its folder and resumes saving when browser permission allows. If it is disconnected, use Reconnect project folder and select the original .sundial folder. Recovery and connection to the shared folder remain separate; check the save notice before relying on disk persistence.

Synchronization health is separate from local recovery. A share can be temporarily unavailable while edits remain in the browser. Sundial retries transient synchronization failures; use Retry synchronization after restoring access and review the remaining notices. Successful recovery does not prove that other users have received the edits.

Browser recovery belongs to the current browser profile and application origin. Clearing site data can remove it. Back up the complete native folder for a durable copy you can move between machines. Reporting snapshots are additional checkpoints and do not preserve the native collaboration history.

6. Edit Project work with structured forms

Browse the hierarchy

Open Project to see the work-item table. Use Search work items, Tasks only, Expand all, Collapse all, and individual disclosure arrows to find the relevant work. The table shows status, effective priority, assignee, estimated and spent hours, deadlines, completion dates, dependencies, sprint links, and color-coded skill labels. An inherited priority has a small arrow beside it. Parent effort and status roll up from descendants.

Work items also have project issue keys, such as APL-13. Keys appear in editors, Kanban cards, sprint lists, and developer assignments; search can use them to find work. They are separate from hierarchy positions and imported source references. Renaming or moving an item preserves its native identity. Concurrent issue creation can trigger a visible renumbering notice when number collisions are reconciled; use the updated key after synchronization.

For a quick estimate change, edit a leaf's Most likely effort (hours) cell directly in the Project table. Press Enter or leave the field to validate and save; Escape cancels the edit. An empty field removes the estimate. Invalid input stays available for correction. Parent totals are derived and cannot be edited this way. Close the work-item editor before editing a table estimate, resolving any pending draft first.

The usual hierarchy is Project → Initiative → Epic → Story → Task. Some diagram specifications call initiatives Releases. A story without children can carry its own estimate. Once an item has children, it rolls up their work and has no separate estimate.

Edit a task

Figure 5. Schedule tab with optimistic, most likely, and pessimistic effort inputs and the PERT expected total.

1. Click the task's name in the table or open its card from Kanban.
2. Edit Name, Status, and Priority above the tabs. Status choices include the current state and its allowed next states; priority can be explicit or inherited. Container status is derived from children.
3. Open the Description tab to write Description and Acceptance criteria. Use the description for context, requirements, and implementation notes. Use acceptance criteria to describe the observable conditions for calling the work complete. Both accept Markdown. Use Preview to check the formatted result and Edit to return to the text. Raw HTML shows as plain text and never runs.
4. Open the Schedule tab for the planning fields: Deadline, start and completion dates, Sprint, Issue link, Assignee, Most likely effort (hours), recorded effort, dependencies, skills, and Parent work item. Set Most likely effort (hours) to the total estimate. With no separate bounds, a 24-hour task with 16 hours spent has eight hours remaining.
5. Click Apply. If validation fails, correct the highlighted errors and apply again. A failed Apply opens the tab containing the first error. Wait for the forecast to refresh.

Cancel discards the current draft. Switching tabs never discards it. Undo reverses a committed edit; cancelling a form after an earlier Apply does not undo it. If Project or Team changed underneath the draft, use Reload draft and review the newer model before entering changes again.

The Audit tab, after Schedule, shows committed changes to this work item, most recent first. Each action shows who made it, the editor's local date and time with its UTC offset, and the previous and new field values. Search the history by person, field, or value. Unsaved drafts and rejected edits do not appear. Undo and redo add new actions while preserving the earlier history. Existing projects start collecting history when auditing is enabled; older changes are not reconstructed.

Figure 6. Work-item Audit tab with search and an empty-history notice on the fresh Example.

Descriptions and acceptance criteria are available for every work item type, including initiatives, epics, and the project itself. These fields are stored with the work item in the native project and are shared with people who open that folder. Acceptance criteria provide written guidance. Marking Done does not run tests or ask you to confirm an acceptance checklist.

Figure 7. Login page Description and Acceptance criteria in the current work-item inspector.

Use the Comments tab to keep findings and decisions with the work item:

1. Enter Markdown in New comment. Use Preview to check the result.
2. Choose Add comment to append it to the current draft and clear the input.
3. Repeat for further comments, then choose Apply to persist them. Text left in New comment must be added or cleared before Apply succeeds.
4. Choose Cancel to discard unapplied additions.

Comments appear oldest first with their creation time. Sundial stores a UTC timestamp and displays an explicit local date and time. Comments are append-only; there are no author fields, mentions, edit controls, or delete controls. They do not change status, scheduling, or acceptance criteria. Concurrent additions merge without replacing each other. Undo can reverse an addition, and Redo restores it. Comments are retained in native storage, recovery, reporting snapshots, and current-project exports.

Figure 8. An unapplied Markdown comment in the work-item Comments tab; the demonstration draft was discarded.

Record effort and status

Spent effort (hours) is an aggregate display. Recorded effort can show an existing starting balance as well as dated entries. To record new work, choose Spent by, set Spent date, enter Add spent effort (hours), choose Add spent entry, then Apply the form. The date and developer identify the entry for later review. These entries are separate from Work tracker's simulated allocations.

Moving an item into a state in the Done category sets its completion date automatically. Leaving the Backlog category can set a missing start date automatically. Handoffs between detailed states in the same category preserve lifecycle dates. Done is terminal: normal editing cannot reopen completed work. Use Undo to reverse a mistaken completion while that edit remains in undo history. Review the dates when updating historical work. If a completion requires moving the reporting start forward, review the proposed reporting-date adjustment before applying. Completion and Undo retain recorded effort history.

Parent status summarizes the descendants. An ordinary Blocked state leaves the work unfinished and prevents future allocation to that item. A canceled state has a separate terminal outcome; its consequences are described in the workflow guide. Check dependencies before relying on downstream delivery dates.

Dependencies, dates, and constraints

Under Assignment and effort, enter Optimistic, Most likely, and Pessimistic total effort in hours. Missing bounds default to the most likely estimate. The ordinary forecast uses PERT expected effort: (optimistic + 4 × most likely + pessimistic) / 6. For the new Example's Login page, 15, 20, and 24 hours give 19.83 expected hours; after 8 hours spent, the expected remainder is 11.83 hours. Monte Carlo samples the same declared bounds rather than treating the ordinary expected date as a percentile.

The dependency picker excludes the item itself, its ancestors and descendants, and choices that would create a cycle. This includes deadlocks involving parent prerequisites and child completion. Apply checks dependencies again against the current project, so a stale picker cannot bypass validation.

An assignee pins work to a particular developer: only that developer contributes to the item during simulation. Unassigned leaf items that fit within two weeks of an average team member's working hours also stay with one developer, chosen at their first simulated pickup. The size threshold is the team's average baseline hours per day multiplied by ten working days; for an eight-hour team, that is 80 hours. It uses the full expected estimate and ignores speed, holidays, availability overrides, and assigned sprint dates. This simulated ownership does not change the saved assignee. Larger unassigned items can receive contributions from multiple eligible developers on the same day, even when their remaining effort falls below the threshold. Each developer uses their own available capacity and speed to reduce the item's shared remaining effort; the estimate remains total person-hours. Eligibility and allocation depend on skills, project access, dependencies, calendars, and each developer's concurrent-work limit.

For a large story that has not yet been refined, leave it unassigned if the forecast should allow several developers to contribute. The simulator assumes their contributions can be combined without a coordination penalty. If some work must happen sequentially, refine the story into child items with dependencies to represent those constraints. A missing estimate leaves the work unknown: it receives no invented finish date and cannot satisfy downstream dependencies. Parent delivery remains incomplete until every required child has a finish. Other estimated branches can still be forecast. Missing references, dependency cycles, and incompatible dates can prevent a valid run. Check that enough capacity is available before relying on the forecast.

The live forecast starts from the later of today's local date and the model's configured reporting start. A later authored start is respected, including one advanced when completing work. The effective reporting end is never earlier than that start. This live adjustment leaves the authored project unchanged. Reporting snapshots preserve the effective window used when captured, while older snapshots replay their saved windows. Standalone milestones are dated commitments that consume no work; simulation can continue beyond the reporting end to completion or its configured limit.

To maintain dated commitments, expand Project milestones above the table:

1. Choose Add milestone, or Edit beside an existing milestone.
2. Enter Milestone name and Milestone date. Names must be unique across the project's work, developers, and milestones.
3. Choose Apply to commit and refresh the forecast, or Cancel to discard the draft.
4. To remove a commitment, choose its Delete action and review the confirmation.
5. Check its date reference in GANTT and the history views.

Milestones provide reference dates; they do not create effort, dependencies, or a scheduled task. Milestone edits use the same draft safeguards, automatic saving, and Undo/Redo as other project edits.

Figure 9. Public beta milestone name and date draft above the current Project table.

Follow links between work, people, and sprints

In the Project table, click an assignee to open that developer in Team, a dependency name to inspect the prerequisite, or a sprint name to open its planning screen. Each link opens the relevant record. Resolve any pending draft before leaving an editor.

Container editors list their Child work items. Search that list and click a child to inspect it, or use the available Add control to create the next level. Use this list to work through a branch without searching the full table.

Add, move, or delete work

1. Hover a parent row and use its + control to add a child. Review the child type and enter its details.
2. If adding a child converts an actionable leaf into a container, review the proposed transfer of its work and sprint assignment before confirming.
3. To move an item, open its form, choose a different Parent work item, and Apply. The subtree moves together. The picker prevents selecting the item itself or one of its descendants.
4. To delete, use the row's delete control or Delete item in the form and review the confirmation. Check the effect on descendants and dependencies.
5. For a deleted task, expand Deleted tasks in Project and choose Restore beside its name. Review restored references and Issues before using the forecast.

Each native work item keeps its identity when you rename it or move it to another parent. Concurrent changes and history continue to refer to that identity. The displayed hierarchy path numbers help you navigate but are not permanent identifiers. Deleted tasks remain recoverable in native history; ordinary editing does not purge them.

7. Define the project workflow

Workflows give your project its own named states and Kanban columns. Each state has a name, color, position, and Simulation category. The category tells Sundial how the state affects scheduling; the name describes your team's process. The default workflow contains Backlog, In progress, Review, Blocked, and Done. Review uses the In progress simulation category. Existing projects with explicit workflows keep their configured states.

Figure 10. Workflow settings with Review, allowed Next states, and the directed transition diagram.

Add or revise states

1. Open Project → Workflow settings.
2. Select a state to rename it or change its color. Use Move up or Move down to change column order.
3. Choose Add state to create another step, then enter a meaningful name such as Ready, Testing, or In review.
4. Choose its Simulation category using the table below. A review or testing step normally belongs to In progress if it should continue to count as active work.
5. For a Backlog-category state, select Default for new work if newly created items should begin there.
6. Under Next states, check the destinations users may choose from this state. Review the directed diagram and its transition list. Click a state in the diagram to edit it; check warnings for states unreachable from the default. A new state also needs an incoming transition if users should be able to reach it.
7. Leave all Next states unchecked to make a state terminal. Done-category states always have no outgoing transitions.
8. Choose Preview changes. Review affected tasks, old and new states, categories, and cancellation outcomes.
9. Choose Apply workflow changes to commit the configuration and affected work together, or Cancel to return to the draft. Cancel the settings dialog to discard it.
10. Open Kanban and check the columns and permitted moves. Review Delivery outlook and GANTT after category changes.

Figure 11. Workflow impact preview before applying changes. This unchanged preview affects no tasks.

Keep at least one ordinary state in every simulation category. The default for new work must belong to Backlog. State identity is stable: a rename or reorder preserves references and does not itself change the forecast. Several detailed states may share a category. Board labels and colors follow the configured states; simulation summaries and status-based diagrams still use the four scheduling categories and their own legends.

The default routes are Backlog → In progress; In progress → Backlog, Review, or Blocked; Blocked → In progress; Review → In progress or Done. To finish work through this default process, move it to Review, then Done. These routes can be changed for unfinished states. Legacy custom workflows without explicit routes allow moves between unfinished states until routes are configured.

Task editors, Kanban menus, drag-and-drop, and native edits enforce the same transitions. A column can remain visible even when a selected card is not allowed to enter it. Done cannot be reopened by an ordinary move or tracker refresh; Undo can reverse a mistaken completion. Moving between detailed states retains a transition history, even when their scheduling category stays the same. Acceptance criteria remain written guidance and do not add a completion prompt.

To remove a state, select it and choose Remove state…. Choose the replacement state for work that references it, review the impact, and apply the change. Resolve references used by defaults or import mappings too. Configuration can remap unfinished work across categories independently of ordinary transition routes, so read the preview carefully. Work already Done may only be reassigned to another Done-category state; removing its state cannot reopen it.

Workflow edits save automatically and support Undo/Redo. If the project changes while settings are open, close and reopen the dialog before applying. The current workflow applies to the whole project; there are no separate team workflows, transition scripts, or automatic transition rules.

Cancel work without deleting its history

Figure 12. Canceled workflow-state draft with Blocked category and terminal outcome; the draft was discarded.

1. In Workflow settings, add a state and give it a clear name such as Canceled.
2. Enable Canceled terminal outcome. Sundial sets its simulation category to Blocked and prevents changing that category while cancellation is enabled.
3. Select the unfinished states from which cancellation should be allowed and check Canceled under their Next states. If canceled work may be resumed later, explicitly allow an outgoing transition from Canceled to the intended unfinished state; leaving it empty makes it terminal.
4. Preview and apply the workflow configuration.
5. Open an eligible work item's form and choose the canceled state, then Apply; alternatively, use an allowed Kanban move into its column.
6. Review the forecast and dependent work. To resume work, use a configured outgoing route, deliberately revise the workflow, or Undo the cancellation while that edit remains available.

Canceled work keeps its identity, description, acceptance criteria, original estimate, dependencies, and recorded effort history. It consumes no future capacity and contributes no effort to simulation scope or completion totals. It is never successful delivery and never satisfies a prerequisite. Cancellation clears successful completion and forecast finish; it does not delete the item or remove dependency links.

If a canceled item is a prerequisite, downstream work can remain unscheduled. Review the dependency and decide whether to reopen the item or revise the relationship. A parent with a canceled descendant stays incomplete. Canceling a container removes its unfinished descendants from future scheduling while retaining completed child history. Reopening the container restores scheduling according to the descendants' retained authored states.

Canceled work cannot be added to a new sprint. If it was already a member, completion records it as Canceled and does not carry it forward as unfinished work.

8. Set priorities and the order of work

Use Urgent, High, Normal, or Low to express preference across the project. An item's Inherit option uses its nearest ancestor with an explicit priority, or Normal if none exists. A container's explicit priority guides descendants that inherit. An explicit Normal overrides an inherited Urgent or High.

Set an inherited or explicit priority

1. Open a work item from Project, Kanban, Sprints, or a supported diagram.
2. Choose a value in Priority, or choose Inherit and review the effective value shown beside it.
3. Choose Apply to commit the edit.
4. Check the Project Priority column, Kanban cards, or sprint planning lists. A small arrow identifies inherited values.

In Example, Login flow is Urgent and Login page and Session tokens inherit it. Normalization is Low. You can inspect these examples to see how inheritance works.

Order unfinished tasks within a priority

Figure 13. Login page with inherited Urgent priority, ordering controls, and formatted Description preview.

1. Open an unfinished actionable leaf and expand Order within … priority.
2. Review its position and the preceding and following task names.
3. Use Move first, Move earlier, Move later, or Move last to change its preference within that priority.
4. Apply the form to commit order, priority, and other draft fields together. Cancel discards them.
5. Review the updated forecast and dependencies.

The ordering pool spans eligible unfinished leaf work across the project, even when a board, sprint, or branch filter hides some tasks. Ordering does not rearrange the hierarchy or change sprint membership. Completed and canceled work do not participate in the active ordering pool. A container passes priority to inheriting descendants, but does not pass its manual position to them.

The scheduler considers deadline urgency before priority and manual order. A task must still meet its dependencies, start constraints, calendar, skill, access, and capacity requirements before pickup. Assignments already started continue. An Urgent priority expresses a preference within those constraints.

Applied preferences support Undo/Redo, shared editing, native recovery, and reporting snapshots. Resolve a stale draft before applying. To view preferences while planning a sprint, use its Priority filter and the labels beside work-item names.

9. Edit the team with structured forms

Use Team to add or edit developers, set their capacity and skills, restrict project access, and maintain working calendars. Apply the forms to save these settings within the current native project. No configuration code or separate Team file is needed.

Open the Team workspace

1. Open your native project, or click Example to explore the supplied demonstration and its snapshots.
2. Select Team in the main workspace tabs.
3. Choose a developer from the roster on the left. Their details appear on the right.

Figure 14. Team workspace with the current developer directory, calendars, skills, access, and assignment links.

The roster lists committed developers in source order, with their locations, default daily capacity, and scheduled override count. For example, "8 h/day + 1 overrides" means an eight-hour default and one override period. It does not show today's capacity or add the override hours to the default. A new developer appears in the roster count after you apply the draft.

Edit an existing developer

1. Select the developer in the roster.
2. Under Profile, edit Name or choose a Location. Choose No location to remove a specific location assignment.
3. Under Availability, set Default hours / day and any Scheduled overrides needed for leave or temporary capacity changes.
4. Review Skills and Project access using the instructions below.
5. Expand Advanced settings if you need to change speed or concurrent work.
6. Click Apply changes. Correct any highlighted errors and apply again if necessary.
7. Wait for the forecast to refresh, choose Diagrams, and review GANTT and Work tracker.
8. Check save notices; Project assignment changes caused by a rename save with Team in the same container.

Form edits remain a Draft until you choose Apply changes, which validates the inputs, commits them to Team, and refreshes the forecast. Until then, the document and roster keep their committed values. Cancel reloads those values and discards the unapplied draft. To reverse an earlier Apply, use Undo.

Open a developer's assigned work

The Work items section in developer details lists their current open assignments, with type, hierarchy context, status, and sprint link where available. Completed and canceled work are excluded from this workload list.

1. Select a developer in Team and scroll to Work items if necessary.
2. Click a work-item name to open its Project editor.
3. Click its sprint name to open that sprint's planning screen.
4. Resolve any unapplied Team draft before following either link.

The list uses the developer's committed name while a rename is still a draft. An empty list means the developer has no open assignments. Their capacity and completed history are separate from this list. Follow a link to edit the task in Project.

Add a developer or create a team

Figure 15. New developer draft with default capacity and profile controls; the draft was discarded.

1. Click + Add developer above the roster. With an empty Team document, use Create team to begin with the first developer.
2. Enter a unique Name and choose a location, if appropriate.
3. Set realistic default daily hours. A new developer starts at eight hours per day, speed one, and one concurrent work item; review these defaults for your plan.
4. Add skills and choose project access. For someone joining later, use the zero-default approach described below.
5. Click Apply changes. The developer is appended to the roster after validation succeeds.
6. Review the resulting forecast and check that automatic saving succeeded.

Use Cancel if you decide against adding the developer. Names must be nonempty and unique; when Project is loaded, a developer name must also avoid conflicting with work-item or milestone names.

Set skills and project access

The Skills section is a table with Skill and Has skill columns. Click + Add skill, enter the skill name, and choose Yes, No, or Unspecified. Color helps distinguish the values, while their text remains visible. Existing names from the project and team are suggested, and you may enter a new name. Use the row's × button to remove a declared skill.

Required skills can be inherited from parent work items. Use consistent skill names, avoid duplicate rows, and apply the draft after editing. Removing a row removes the declared skill entry; it is distinct from retaining a row as Unspecified.

For Project access, leave Access at All projects for scheduling eligibility across the model. This setting controls work assignment eligibility, not permission to open the shared folder; filesystem permissions control that access. To restrict eligibility:

1. Choose Selected projects.
2. Enter a project or initiative name using the suggestions where possible.
3. Click + Add project to create a chip for that name.
4. Repeat for other allowed names, then click Apply changes.

Keep at least one chip when using Selected projects. To remove all restrictions, choose All projects. If the roster includes a project name absent from the loaded project, the form preserves it and marks it Not in this project. Access does not define separate daily hour budgets for each initiative.

Model default capacity, leave, and temporary hours

Figure 16. Bruno's default capacity and dated zero-hour override in the Team editor.

Default hours / day is the developer's capacity on working days outside override periods. A scheduled override replaces that value during its interval. Eight default hours and a four-hour override produce four hours on covered working days. Overrides do not add hours to the default. Weekends and location holidays remain non-working days even when an override has positive hours.

To record leave or a temporary allocation:

1. Select the developer and review Default hours / day.
2. Under Scheduled overrides, click + Add override.
3. Set From, Until, and Hours / day for the new period. A new row copies the current default hours and leaves its dates blank, so fill the intended bounds deliberately.
4. Use zero hours for time off, or a positive value for temporary part-time or increased capacity.
5. Add further periods if needed, keeping their dates separate.
6. Click Apply changes, review the forecast, and check automatic saving.

Hours must be from zero through 24, with at most two decimal places. Both dates are inclusive. A one-day override is valid when From and Until are the same date. From must not be later than Until. Overrides cannot overlap: one ending on the next one's start date overlaps on that day.

A blank From means no lower date bound; a blank Until means no upper bound. Leaving both blank covers every date and conflicts with any other override. Do not leave bounds blank unintentionally. Remove deletes a period from the draft; after Apply, the default resumes over that period.

For a developer who should contribute nothing before joining, set the default to zero and add an override starting on their joining date with the intended daily hours. Leave Until blank for an ongoing allocation. For capacity available only during specific periods, keep the default at zero and give each period its own bounds. Review the default explicitly: an override list alone does not imply zero capacity outside its dates.

Adjust advanced settings

Expand Advanced settings to edit:

Set daily hours to the time available for this plan. Change speed only when you have a credible reason to adjust the productivity assumption. Apply and inspect the resulting schedule before accepting new assumptions.

Below Advanced settings, expand Audit to review changes to this developer profile. It starts collapsed. Actions show the signed-in user, local date and time, and previous and new values, most recent first. Use its search box to find a person, field, or value. Renaming a developer keeps their profile history together.

Figure 17. Developer Audit section below Advanced settings; the fresh Example has no committed profile edits.

Manage locations and working calendars

Figure 18. Germany working calendar with country and region fields, weekend controls, and extra non-working dates.

1. In Team, find Locations below Developers in the left sidebar.
2. Select an existing location, or click + Add location.
3. Enter a unique Location name.
4. Enter an optional Country code to use public holidays. Add an optional Region code when regional holidays are relevant; the region must belong to the chosen country.
5. Select the non-working Weekend days. New calendars start with Saturday and Sunday selected.
6. Under Extra non-working dates, click + Add date for each company closure or additional holiday. Use Remove to remove a draft date; duplicate extra dates are rejected.
7. Click Apply changes.
8. Select the appropriate members directly under Developers in the same sidebar and assign their Location. Apply each changed developer draft.
9. Check automatic saving and review the forecast.

Public holidays come from the holiday service; the extra-date list contains the closures you enter. Fetched holidays are not copied into that list. If a fetch fails and no cached data is available, read the warning. A forecast using only weekends and extra dates may finish too early.

Renaming a location updates matching developer location references in the Team document as one change. To delete an unused location, use its Delete button and confirm. If developers still reference it, first choose another location or No location for each affected developer and apply those edits; deletion is blocked until the references are removed.

Rename or delete a developer safely

To rename a developer, select them, edit Name, and click Apply changes. Sundial renames the Team member and updates matching task assignees in the loaded Project as one committed change. The form shows how many assignments it will update. All changes save in the same native project.

If Project references cannot be updated safely, the rename is blocked. Correct the reported Project issues and retry. The rename affects the current native project; it does not rewrite other project folders.

To delete a developer, open the row's ••• menu, choose Delete developer, and confirm. Sundial blocks deletion of the last developer and of a developer still named in task assignments. Update or remove those assignments in Project first. For a temporary staffing experiment, uncheck the person in Team what-if instead of deleting them from the reference team.

Drafts, automatic saving, snapshots, and undo

Figure 19. Unapplied-changes dialog offering Apply changes, Discard changes, and Keep editing.

When changing developer, leaving Team, opening another project, or capturing a snapshot with a pending draft, resolve the dialog: Apply changes commits valid edits, Discard changes continues with the previous committed document, and Keep editing returns to the draft.

If automatic saving fails, restore folder access and use Retry. Browser recovery does not prove the shared folder is current. Closing a notification leaves the draft unchanged; it does not save or discard it.

Resolve form errors and return to the diagrams

If validation fails, the form keeps your entries and shows Changes were not applied, with errors beside the affected fields where available. Correct duplicate names or skills, missing access chips, invalid numbers, conflicting periods, or calendar codes, then apply again. The first invalid control receives focus when Apply fails.

If the underlying Project or Team changes while you have a draft, use Reload draft to work from the newer document; stale edits cannot overwrite it. Review collaboration and validation issues before applying again.

After accepting a valid edit, choose Diagrams, wait for Ready, and inspect GANTT, Work tracker, and Delivery outlook. Applying the reference team also refreshes staffing comparisons; scenario-only additions and exclusions stay separate. Blocked work, dependency chains, skills, project access, pinned assignees, future availability, weekends, and holidays still constrain the forecast.

10. Track work in Kanban

Kanban displays actionable leaves in columns for the project's configured workflow states. The default workflow has Backlog, In progress, Review, Blocked, and Done. Containers provide hierarchy context; only actionable leaves appear as cards.

Figure 20. New Example Kanban board with Review, issue keys, assignees, priorities, effort, and filters.

Cards show the project issue key, work name, sprint, effective priority, type, assignee, and spent/estimated effort. Inherited priority carries an arrow. Use Workflow settings in Project to add or rename process steps and choose their scheduling categories.

Review and update work

1. Open Kanban.
2. Choose Scope → All project issues, No sprint, or a named sprint.
3. Choose Developer to show all developers, a member, or unassigned work.
4. Choose Group by → Status only, Developer, or Epic. Developer and Epic create swimlanes across status columns.
5. Use Columns to hide or show status columns. Hiding a column does not change task status.
6. Open a card to inspect and edit its work-item form. Review assignment, estimate, recorded effort, dependencies, and sprint membership, then Apply. The card's Description and Acceptance criteria stay off the board for compactness; opening the card shows the full formatted text with the same Preview toggle as the Project form.
7. Drag a card into an allowed next-state column, or use the card's menu and Change status. The menu lists permitted destinations; a disallowed drop cannot change the task. With the default workflow, move active work through Review before Done. The change commits and saves automatically and refreshes the model. Same-category handoffs preserve lifecycle dates; category changes use the scheduling and completion rules described in the workflow guide.

To change an assignee, open the issue inspector, even when the board is grouped by developer. Dragging changes status only. Dropping a card into its current status or outside a valid target leaves it unchanged. Resolve any unapplied inspector draft before navigating away or continuing an action that prompts you to review it.

Each column shows up to 30 cards per page. Check the totals and pagination to see whether more work is available. The page size does not impose a work-in-progress or capacity limit. A missing assignee reference can appear separately from unassigned work; correct the reference in Project/Team.

Kanban filters affect the board only. Forecasts still use the full dependency graph and Team. Sprint scope is remembered for the project. A completed sprint's historical board is read-only; use Open live issue to edit the corresponding current task.

11. Plan, run, and complete sprints

Sprints group actionable work into a named period with inclusive start and end dates. Membership is independent of task status and does not replace dependencies or forecast constraints. The Sprints workspace lists Planned, Active, and Completed sprints.

Figure 21. New Example active sprint with current scope, unscheduled work, and per-developer capacity.

Create and populate a sprint

1. Open Sprints and choose + Create sprint.
2. Enter a useful name and inclusive start/end dates, then choose Create. New sprints use the browser's local timezone; the form does not offer a timezone picker. Use Edit sprint → Save for subsequent changes.
3. Select the planned sprint in the list.
4. Search work, filter by developer, or expand Priority and select the priorities to include. In Unscheduled work, use Add for one item or select several and choose Add selected to sprint.
5. Expand Assign other work or a parent subtree when you need to bring in other work or all eligible leaf descendants of a parent. Review affected issues and any assignments that will be replaced.
6. Under Sprint scope, use Remove or select several and choose Remove selected to leave them unscheduled.
7. Review remaining effort, unestimated work, unassigned work, and developer capacity. Adjust assignments, scope, or dates before starting.

You can also choose a sprint in the Project task form. Assigning a subtree adds its eligible actionable leaves; the parent contributes no extra estimated work. Committed sprint planning actions save automatically.

Review priorities and inspect planning items

Figure 22. Sprint planning with the Priority filter expanded and the new Example scope.

Unscheduled work is presented by effective priority, then by scheduling status, with active and blocked work ahead of waiting work. Manual order expresses a forecast pickup preference; it does not determine this list's status grouping. The current Sprint scope remains a membership list; moving a task's priority does not remove it from the sprint.

Click a work-item name in either planning list to open its editor and review Description, Acceptance criteria, Comments, and Schedule. Apply changes to the same project record, then return to planning. You can also drag eligible work between the two planning lists to add or remove membership; the explicit Add/Remove buttons provide the same actions.

Filters hide rows for review; they do not exclude those members from total scope or capacity. Canceled work is not offered for new assignment and contributes no remaining capacity demand.

Interpret Sprint capacity

The capacity panel compares Estimated work / calendar hours for all developers and for each member. The workload is remaining estimated effort; Done and canceled work contribute no remaining demand. Calendar hours use Team defaults, overrides, weekends, holidays, and extra non-working dates. Planned sprints use their full period. Active sprints start at the later of today and their start date, through the inclusive end. Date edits refresh the preview; invalid dates or ranges beyond ten years cannot produce a capacity preview.

The total includes unassigned work and identifies it separately; each developer's row includes only their assigned work. A percentage above 100% means estimated demand exceeds calendar hours. Missing estimates make demand incomplete. This comparison does not adjust hours for developer speed, account for scheduling constraints, or deduct work outside the sprint. It does not predict a delivery date or enforce a Kanban WIP limit. Use GANTT and Work tracker for the forecast, especially when speed differs from one or work has dependencies.

Start and review the sprint

1. Select a Planned sprint and choose Start sprint.
2. Review the issue counts and warnings. Starting requires unfinished work; only one sprint can be Active in a project.
3. Confirm the start. It creates no reporting snapshot or commitment baseline automatically.
4. Choose Open board to review the sprint in Kanban. Update statuses and recorded work there or in Project.
5. Return to Sprints to review scope and remaining capacity. Dates do not automatically start or complete a sprint.

Complete and carry unfinished work forward

Figure 23. Sprint completion review with a destination for unfinished work; the dialog was canceled.

1. Select the Active sprint and choose Complete sprint.
2. Review all member issues, including filtered or hidden work, the Done count, unfinished items, and canceled members. Canceled work has its own final disposition and is not carried forward.
3. Choose whether unfinished work should Leave unscheduled, move to a Planned sprint, or go into a newly created next sprint. Review the destination before confirming.
4. Confirm completion. Task statuses remain unchanged; the destination sprint remains Planned.
5. Verify the completed sprint in the list and its completion checkpoint in History.
6. Open its historical board to see the captured end state before carryover. Use Open live issue when you want the current item rather than the historical record.

Completing a sprint saves its final board and a full Project-and-Team reporting snapshot. Completed boards are read-only and can be archived. They retain the workflow state names, colors, order, scheduling categories, cancellation outcomes, and configuration captured at completion, so later workflow edits do not rewrite the historical board. If snapshot storage fails, completion remains applied and Retry snapshot retains the original completion payload. Restore or reconnect the snapshot store before retrying. A native project-save failure has a separate retry action.

Undo reverses completion and carryover but retains the already saved checkpoint. Redo reuses that completion checkpoint.

12. Import Jira data

Use this optional import path when you want to bring existing Jira work into Sundial. Imports use saved files; Sundial does not continuously synchronize with Jira or write local edits back to it. After import, manage the project through Sundial's own work, team, workflow, and sprint screens.

Figure 24. Import panel with tracker-dump selection, optional mapping, forecast window, and replacement options.

Prepare a CSV export

1. In Jira's issue navigator, filter for the complete work set you want Sundial to model. Include parent levels and completed work relevant to the project.
2. Export CSV with the required fields. Choose fields that include keys, summaries, hierarchy, status, estimates, assignees, and dates. All fields can supply them but produces a larger, slower export; a configured current-fields export can be smaller.
3. Include Issue key and Summary. Include parent/epic references, estimates, due dates, assignees, Created, and Resolved wherever relevant.
4. Confirm that the exported issue set matches the result set you intended. Permissions and export limits can omit work without making Sundial's import fail.
5. Keep the export as UTF-8 CSV and retain a source copy.

Atlassian currently documents asynchronous Jira Cloud CSV exports of up to 10,000 work items. Other Jira deployments and export paths can have different limits. For larger result sets, follow your deployment's export process and verify completeness. See Atlassian's CSV export guidance.

Sundial accepts one CSV file per import. It rejects multiple CSV files and selections that mix CSV with JSON. Prefer one complete, consistent export. Native refresh reconciles known issues; fresh import replaces the model. Check the complete work set rather than assuming successive filtered exports cover the project. Consolidate compatible CSV exports correctly, or select a complete set of JSON dump files.

Import into Sundial

1. Back up the whole native project folder. Capture a reporting snapshot if you want a before-import baseline.
2. Click Import in the header.
3. Under Dump file, select one CSV, or one or more supported JSON dump files.
4. Select a Mapping YAML file if your workflow, estimate field, date format, or column names need overrides.
5. Set Reporting window start to the date represented by your planning model. Its default is the current UTC date.
6. Choose whether to Seed a fresh project. Enable it to replace the open document and seed developers from dump assignees. Disable it when refreshing an existing project whose team and settings should remain.
7. Click the dialog's Import button.
8. Read the imported item/project counts and all warnings. On failure, the current document remains untouched.
9. Close the dialog, review the result in Project and Team, and wait for a successful simulation.
10. Correct seeded staffing assumptions, verify automatic saving, and capture a reporting snapshot explicitly. A first import can create a native project and request a folder location.

A fresh seed requires at least one assignee in the dump. Review each generated developer's skills, daily allocation, concurrency, location, and availability before relying on forecast dates.

Refresh versus fresh import

A native refresh reconciles tracker work with existing items. Matching prioritizes the immutable Jira issue ID, then the Jira instance and issue key, then an existing explicit mapping. Matched items keep their Sundial identity and creation time. Sundial also keeps issues missing from a filtered export, because the export does not establish that they were deleted.

Tracker-owned field updates can replace your local edits to those fields. Review the source data, import warnings, and resulting changes. Preserve existing team/calendar and planning assumptions when using refresh rather than a fresh seed.

Refresh is blocked when the project has local sprint metadata because those assignments cannot yet be reliably preserved by this workflow. Seed a fresh project deliberately replaces the Project model, including its sprint plans and completion history. Back up the complete native history before choosing it. Keep a reporting checkpoint too if you need a comparison baseline.

Refresh also preserves recorded effort dates and the developer names attached to entries. If the tracker total is higher, the difference is added to the undated starting balance; Sundial does not invent dates or attribution. A lower tracker total stops refresh for reconciliation rather than removing recorded hours. A leaf with an effort audit cannot become a container through refresh until its recorded work has been moved to a leaf. Refresh can skip intermediate unfinished states, but it cannot reopen Done work.

By default, supplied issues update the existing model while other projects, omitted issues, and existing milestones remain. An optional mapping can request complete snapshot replacement through importMode; review that choice separately from the dialog's fresh-project option.

Import does not automatically create a reporting checkpoint. Automatic native persistence and Snapshot are separate operations.

CSV fidelity: understand what is missing

When reviewing dependency cascades or historical schedules, check these limitations alongside the import result. An import can succeed even when the export is incomplete.

JSON and NDJSON dumps

The browser accepts saved Jira search response objects, arrays of issue objects, and NDJSON containing one issue object per line. Multiple JSON dump files can be selected in one run. Duplicate issue keys favor the newest updated value; ties or missing timestamps retain the first occurrence.

A JSON dump can include issue links for dependencies and changelog data for more accurate historical transitions. Check that those details are present in your files. Sundial does not retrieve missing pages or enrich the dump from Jira. Make sure your saved files cover all pages and contain the fields you need.

Configure a mapping file

Use the optional mapping file to select your Jira profile, date order, estimate field, points-to-hours conversion, status mapping, duration units, and policy for missing estimates. Use a points-to-hours conversion justified by your team; the Fibonacci option selects Sundial's fixed mapping instead. The mapping's duration scale describes Jira's duration notation, not a developer's calendar capacity.

The default unestimated policy is error. Alternatives are skip or an explicit fallback such as hours:8; both change the model and should be disclosed in reports. Column overrides can map canonical fields to localized headers, such as a localized Summary column. Supported profiles are cloud, server, and apache. Unknown mapping keys are errors.

Map imported statuses to the project workflow

Before refreshing a project with a configured workflow, open Project → Workflow settings and expand Tracker status mappings. Enter each exact Jira status name and choose its Sundial state. Include spelling and case as exported, then preview and apply the configuration. Several source statuses can map to one state.

An unmapped source status stops a configured-workflow refresh rather than silently putting that issue into Backlog. Review the import error, add the missing mapping, and retry. Choosing a mapped canceled state applies Sundial's cancellation rules; choosing a Done-category state uses successful completion rules and valid imported completion dates.

Matched refreshes preserve Sundial-authored descriptions, acceptance criteria, comments, priorities, manual ordering, and detailed-state audit history. Jira priority does not set Sundial priority. Tracker-owned fields can still change during refresh, so inspect the result and warnings. Fresh import is a replacement operation and is covered separately above.

13. Choose the right diagram

Common diagram controls

1. Choose Diagrams in a large desktop window. Close any work-item editor to give the chart the full workspace.
2. Use Hide details in Delivery outlook if you need more chart height.
3. Start with the fitted overview. Use Zoom in, Zoom out, and Fit to move between detail and the whole diagram.
4. Use Ctrl+wheel to zoom around the cursor. Scroll to explore content larger than the pane; horizontal scrolling or Shift+wheel helps wide schedules.
5. Hover marks for details. Chart labels can be shortened to fit; tooltips supply fuller context.
6. Use Show title when capturing or exporting a self-contained report image.
7. Use the diagram toolbar's SVG or PNG control to export that diagram.

Edit work directly from a diagram

In the current WBS, GANTT, and Sunburst views, click a work item to open its editor beside the chart. Use the same Name, Status, Priority, Description, Acceptance criteria, Comments, and Schedule controls described in the Project guide. Apply commits to the shared project and refreshes its forecast; Cancel discards the draft. Close the editor to return to the full diagram. Disclosure markers expand branches rather than opening the editor.

You can review a branch and update its planning data beside the chart, then check the resulting dates without returning to the main table. Comparisons and historical views remain reporting views; use the current workspaces to edit live work.

The canvas grows to fit its content. Use Fit for an overview, then zoom and scroll to inspect details at their natural size. Exports use the whole chart canvas, regardless of the current viewport zoom.

14. WBS: inspect scope and status

A work breakdown structure is a hierarchy of deliverables and their component work. It helps establish scope before reviewing dates. PMI discusses the value of deliverable-oriented decomposition in Scheduling 101.

Figure 25. Redesigned WBS using the expanded Example hierarchy, assignee labels, and Goal and Late goal borders.

Step by step

1. Click WBS.
2. Follow the hierarchy from the project root through initiatives and epics to leaf work.
3. Use a node's disclosure control to expand or collapse a branch. Expand all reveals branches; Collapse all produces an overview.
4. Enable Count done or Count backlog to group those sibling items into counters. Disable the options when individual names are needed.
5. Toggle Assignees to show or hide ownership in captions.
6. Hover an item for details. Click its box to open the work-item editor when you need to revise description, status, priority, or planning fields.
7. Export the configured view for a scope or status review.

Read the colors

Use the WBS legend: done is green, in progress is yellow, backlog is pale blue-gray, and blocked/problem states are red. An incomplete item with a deadline retains its status fill and gains a thick goal border: red when its deadline has expired at the view date or its forecast finish is later than the deadline, green otherwise. Blocked work keeps a red border. The deadline appears in the caption. Use each chart's own legend; Sunburst uses amber for in-progress work.

A container's effective status summarizes its subtree. Counters are presentation aids and do not create or remove source work. A hidden branch still contributes to the model and to rolled-up dates and effort.

15. GANTT: review the delivery schedule

A Gantt chart places work on a calendar so durations, sequencing, and overlaps are visible. Asana's Gantt overview provides background on this chart family. Sundial calculates unfinished work's schedule from the model; manually entered dates alone do not determine it.

Use Start date to choose the visible GANTT window; clear it to include all history. Show hi-low ranges overlays the optimistic and pessimistic scenario finishes around the PERT expected schedule. These are coherent scheduling scenarios, not Monte Carlo percentiles. Show dependencies toggles dependency connectors. The new Example includes varied effort bounds so these differences are visible.

Figure 26. Current GANTT with PERT hi-low ranges, dependencies, start-date control, deadlines, and the Public beta milestone.

Step by step

1. Click GANTT.
2. Use Root to choose the whole project or a particular container, then locate the initiative or epic of interest in the row labels.
3. Expand its disclosure marker to reveal the next level. Use Expand all for more detail or Collapse all to return to the configured depth.
4. Read the start and finish against the time axis. Hover the bar or caption for precise dates and details. Click a work item to open its editor; close it for the full schedule.
5. Follow visible dependency connectors to understand sequencing constraints.
6. Compare the forecast finish with the deadline marker. Standalone milestones such as Public beta appear as separate vertical reference lines.
7. Zoom into the relevant interval and scroll as needed. Enable Show title before exporting.

The now line marks the effective forecast start: normally today, or a later configured start. Container spans include historical completed children as well as future work. Long breaks can split a summary bar; a continuous stretch does not imply work on the parent every day. Missing child forecasts prevent a complete parent delivery date. Completed work retains recorded ownership in reports. Gaps and short allocations reflect calendars and sequencing; use Work tracker to inspect simulated person-hours.

16. Sunburst: see effort and health at a glance

A sunburst displays a hierarchy as concentric rings. Descendants sit outside their parents; segment widths encode relative values. See Plotly's sunburst explanation for the general structure and Tommesani's article on project health with sunburst diagrams for its project-reporting use.

Figure 27. Current Sunburst showing the new Example hierarchy and status-colored PERT expected effort.

Step by step

1. Click Sunburst.
2. Leave Root set to Project for a whole-project picture.
3. Read outward from the center to follow initiative, epic, story, and task relationships.
4. Compare widths within a ring to find effort-heavy areas. Parent totals derive from children, avoiding double counting.
5. Read the legend: green is done, amber is in progress, red is blocked, and pale blue-gray is backlog.
6. Hover a segment for its name, status, effort, and share.
7. Select an initiative in Root to focus the chart on that branch, then return to Project for the overall picture.
8. Click a segment to open the live work item when you need to inspect or edit it. Close the editor, then export the view for a project-health overview.

Arc width shows total estimated effort. It does not measure remaining hours, duration, or percentage complete. The selected root is named in the center; segment captions follow their arcs where space permits. Narrow labels may be hidden, so hover to read them. Container status summarizes the subtree and does not imply every descendant shares that status. The Sunburst tab shows the current state. Use Sunburst over time to compare checkpoints.

Sunburst over time places up to two saved snapshots beside Current, ordered by capture time. Every chart has the same radius. The largest valid total effort fills a circle; earlier or smaller totals occupy a proportionally smaller angular span, leaving a gap. The shared scale makes scope growth visible across periods. Colors retain the status meanings from Sunburst.

1. Open Sunburst over time and choose a saved checkpoint in Historical snapshot 1.
2. Optionally choose a different checkpoint in Historical snapshot 2. Choose No snapshot to remove a saved period; Current remains visible.
3. Leave Root at Project, or choose an initiative to use the same focus in every chart.
4. Compare the occupied angle, status segments, total estimated hours, and percentage complete beneath each chart. The completion percentage compares worked effort, including completed work, with total estimated effort.
5. Use Zoom in, Zoom out, and Fit for inspection. A root or snapshot change resets zoom.
6. Enable Show title, then use this tab's SVG or PNG button to export the comparison as one image.

The saved charts use each snapshot's own work, effort, and status. They do not forecast its history again. Missing or invalid effort, an absent selected root, or an unreadable snapshot produces a notice for that period. Zero effort has no angular span. These gaps do not mean completion. Without snapshots, Current still appears; capture a checkpoint or load Example into an empty reporting store to add comparison periods. These snapshot choices are independent of the two Delta views.

Figure 28. July, August, and Current Sunbursts sharing an effort scale with the expanded Example.

17. Work tracker: inspect resource allocation

The Work tracker is a heatmap: rows represent developers, columns represent time, and cell intensity represents allocated work. Heatmaps encode numeric magnitude by color; Plotly's heatmap documentation illustrates the chart family.

Use Day or Week under Resolution, and Hours or Capacity under Values. Capacity compares allocation with the developer's available hours. The current drawing distinguishes weekends, holidays, and available but unallocated time, and adds Goal deadline and milestone references. Developer labels summarize allocations; hover cells and markers for their details.

Figure 29. Redesigned daily Work tracker with developer allocations, availability, Goal deadlines, and milestone references.

Step by step

1. Click Work tracker.
2. Use Day to inspect daily allocation for each developer.
3. Hover a cell to read the allocated hours and contributing tasks.
4. Inspect non-working-day details when available. A weekend, holiday, zero-capacity override, or zero default can explain an empty cell; on a working day, there may simply be no allocated work.
5. Select Week for a long interval. Each weekly cell shows average hours per visible calendar day; the tooltip supplies the week's total and task contributions.
6. Switch Values → Capacity when you need to compare utilization with available capacity rather than raw hours.
7. Look for persistent empty working periods or long stretches of high allocation, then check dependencies, skills, and capacity assumptions.
8. Export the chosen daily or weekly presentation.

For an empty cell, check whether the person is unavailable, waiting on dependencies, ineligible for the remaining work, or has finished the work in the model. The heatmap shows Sundial's simulated allocations and does not import real-world timesheets. Weekly averages include visible non-working days, so they need not equal a person's nominal working-day hours.

Figure 30. Work tracker Capacity mode showing allocation relative to each developer's available hours.

18. Monte Carlo simulation

Open Diagrams → Monte Carlo and press Start. Sundial samples each unfinished leaf's total effort from a Beta-PERT distribution using its optimistic, most likely and pessimistic estimates (lambda 4). Missing bounds default to the most likely estimate. Equal bounds produce fixed effort. Spent effort is subtracted by the ordinary scheduler, completed history remains fixed, and parent completion dates roll up through Epics, Initiatives and the Project.

Figure 31. Stopped Monte Carlo run with Project and Initiative distributions and the P50, P85, and P95 table.

The computation runs in a background worker. As soon as the first iteration completes, the diagram and percentile table appear with that single sample. They then refresh together at most once every five seconds. The green calculator-style counter shows completed iterations and refreshes at most once per second after the first result. The counter may therefore be ahead of the displayed diagram; cell percentages and percentiles always use the iteration count printed on that diagram.

The heatmap follows the GANTT hierarchy and its initial root/depth settings. Expand or collapse rows using their disclosure controls. The timeline extends from Now to the latest simulated completion date. Dark blue means no completion on that day; bright red marks the most frequent day within that row. Each row is normalized independently, so colors do not compare raw counts between work items. Hover a day to see the date, occurrence count and percentage of completed iterations. Historical completions before Now remain in the percentile statistics but lie outside the heatmap window.

Violet vertical bars mark milestones; red row ticks mark Goal deadlines, using the GANTT conventions. Inherited deadlines continue through descendant rows, with the label shown only where that deadline begins. Hover a marker to read its name and date. The timeline extends far enough to show future milestones and Goals even when they fall after the latest simulated completion; exports include these markers.

Expand Completion date percentiles to see Project and Initiative P50, P85 and P95 dates. For example, P85 is the earliest date by which at least 85% of completed iterations finished that item. Percentiles use the empirical nearest-rank rule. Iterations without a completion date count toward the denominator; if too few iterations finish the item, the corresponding percentile is unavailable.

Stop finishes and counts the current iteration, then immediately refreshes all results. Leaving the Monte Carlo tab also stops computation after the current iteration. Returning shows the existing results without resuming. Pressing Start again clears them and starts a fresh run.

Each run uses a temporary in-memory copy of the inputs captured at Start, including resolved holidays. Edits do not change an ongoing run. This copy creates no saved Snapshot and adds no entry to History. Monte Carlo results are not saved with the project and disappear on reload or project replacement. Use Export SVG or Export PNG to preserve them; the export includes the heatmap, represented iteration count and the percentile table, even when the table is collapsed on screen.

19. Capture and manage snapshots

A snapshot stores the combined Project and Team model with a UTC capture timestamp. It is the checkpoint used by Delta comparisons and history charts. Automatic native saving does not add a reporting checkpoint. Native startup snapshots belong to the collaboration container and serve a different purpose.

Figure 32. History panel with the Example July and August checkpoints and storage controls.

Capture a checkpoint

1. Finish the update and resolve model errors.
2. Wait for a successful current run.
3. Click Snapshot, or press Ctrl+Shift+S.
4. If the browser requests a folder on first capture, choose a dedicated snapshot location. Cancelling that initial picker can use browser storage instead.
5. Open History and verify the new checkpoint is listed. Check the storage indicator and any capture notice.

New checkpoints freeze the effective live forecast window as well as the committed work and Team. Historical replay can therefore reproduce the captured dates even after the current date changes. Older checkpoints keep the window saved in them.

Dated files use a name such as 2026-09-30-093005Z.yaml. The timestamp is UTC, so a capture near midnight can have a different calendar day from your local date.

Browser storage and folder storage

Browser storage belongs to one browser profile and application origin. Clearing site data can remove the stored buffers and history. Use a separate backup when you need a copy you can move between machines.

Where supported, Choose snapshots folder… selects the active file-based store. Sundial writes dated snapshot files directly into the folder you choose. Select a dedicated snapshots folder for the project, then confirm its contents and the History indicator. Maintain a separate series for each project. When you switch storage targets, Sundial copies the current project's readable reporting history before changing the active target. Conflicting filenames are preserved under distinct names. If copying fails or the old folder cannot be read, the switch is blocked and the previous target remains active. Reconnect a lapsed folder first, then check History after a successful switch.

If permissions lapse after a browser restart, choose Reconnect snapshots folder… and grant access again. If you see a permission error, restore access before checking whether snapshots are missing. Use browser storage first copies the project's readable history into browser storage, then changes the active target. It leaves the old folder files intact. Browser quota or read failures block the switch.

Use History actions

• Load replaces the current model with the saved checkpoint after a replacement confirmation. Back up the native project first and review the warning; use a comparison baseline when you only want to compare dates. Existing append-only comments are retained when loading an older checkpoint. Loading changes the model; it does not simply open a chart or reconnect a native folder.
• Δ WBS or Δ GANTT selects the snapshot as a baseline and opens the corresponding comparison against the current model.
• Refresh the series rereads available checkpoints, useful when files have changed outside the browser.
• Delete removes a checkpoint. Back up file-based history before deleting; do not rely on an application undo or trash facility.

Example adds demonstration checkpoints only when the active store is empty. If you already have history, check the list to see which project and checkpoints you are comparing.

20. WBS over time: explain what changed

Delta WBS shows changed work in its hierarchy. It retains ancestors for context and omits unrelated siblings. This kind of filtered status report is described in Tommesani's article Changes, or what did we do last month?.

Figure 33. WBS over time comparing the August checkpoint with the expanded current Example.

Compare a checkpoint with the current model

1. Click WBS over time.
2. Under Compare, select the baseline snapshot.
3. Leave with set to Now.
4. Read the diagram title to confirm the endpoints, and check for any stale-current warning.
5. Follow changed branches. Enable Assignees if ownership is relevant.
6. Hover changed nodes to inspect before-and-after status, assignee, and other reported field changes.
7. Export the view for a change review.

Colored nodes represent qualifying changes, including additions, status changes, completion, ownership or hierarchy changes, and removals. Gray ancestors locate those changes. Removed nodes use a distinct light-red/struck treatment and have no current-state reading. A gray ancestor can still have a meaningful unchanged status in its tooltip.

Compare two saved checkpoints

1. Select an older snapshot under Compare.
2. Under with, select a later saved snapshot.
3. Confirm the period shown in the title.
4. Switch to GANTT over time to inspect schedule movement for exactly the same pair.

Figure 34. WBS over time comparing the saved 13 July and 17 August checkpoints.

Only snapshots strictly newer than the baseline are offered as saved endpoints. If no later capture exists, the end control may offer only Now and be disabled. Changing the baseline can reset an invalid end choice to Now. The comparison pair is shared by both Delta tabs.

An empty result may show No qualifying changes even when the source work is present. WBS over time compares the hierarchy and status fields used for reporting; it does not audit every edit.

21. GANTT over time: explain delivery movement

Figure 35. GANTT over time comparing the August checkpoint with the current Example schedule.

Step by step

1. Click GANTT over time.
2. Select the baseline and comparison end. The pair is shared with WBS over time.
3. Keep Show dates enabled when exact movement needs to be visible in the report.
4. Read each moving row's baseline and comparison delivery dates.
5. Use the legend to distinguish earlier finishes, later finishes, changed rows, delivery movement from re-anchoring, new work, and removals.
6. Expand a container to reveal changed descendants. Unchanged siblings do not become a full schedule just because you expand.
7. Follow hierarchy and highlighted dependency relationships to investigate a possible cascade.
8. Compare moved finishes with deadline and milestone references, then export the configured report.

Use Root to focus on a container without changing the comparison endpoints. The view focuses on meaningful schedule differences. An effort change appears in this view when it moves dates. A revised estimate alone is not reported as a duration change. Changes that finish entirely before the comparison window's historical cap can be omitted. The window starts seven days before the older endpoint's date so old completed history does not dominate the report.

Changing reportingPeriod.from can carry delivery dates forward even when work's position relative to the planning start stays similar. Sundial distinguishes this re-anchoring from a conventional delivery slip. Live Now also advances with the current local date unless a later start is configured. Read the calendar dates and legend before attributing a rightward movement to a delay in the team's work.

Dependency connectors show the relationships in the model. Links missing from a CSV export remain missing from the chart, so check the source data before attributing a date change to a dependency.

22. Scope: track estimate growth and reduction

Scope is a stacked-column history chart. Canceled effort is excluded from its simulation-based totals even though the original estimate remains stored on the work item. Each column shows the known total estimate at an observation; its colored segments show the selected root's constituent groups.

Figure 36. Scope history with July and August checkpoints and the larger current Example; totals use PERT expected effort.

Step by step

1. Make sure the active history contains a saved snapshot.
2. Click Scope.
3. Leave Root set to Project to compare initiative/Release totals.
4. Read the observation labels horizontally and Estimated effort (hours) vertically.
5. Compare column totals, then identify the segments responsible for growth or reduction.
6. Hover a segment for the group, checkpoint, effort, and completeness details.
7. Choose an initiative/Release under Root to compare its direct epics instead.
8. Switch to Milestones to inspect delivery drift for the same selected root.

Scope counts the full declared estimate, including completed work still present. Spent work is not subtracted. A rising column can reflect added work or revised estimates; a falling column can reflect descoping, removal, or reduced estimates. Completion alone does not shrink the scope total.

Saved observations are grouped by UTC calendar day, using the latest capture on that day. Current is a separate live column from the latest successful current model, placed last. It is not another saved checkpoint. No columns are invented for days without snapshots. Missing estimates make the known subtotal partial; do not interpret omitted estimates as zero work.

Series colors identify groups and remain consistent within the history views. Native work has persistent identities across rename and reparent operations. Older reporting snapshots without stable identities can still fall back to a path, shown as (path id); review continuity when comparing older exports.

23. Milestones: track delivery forecast drift

The Milestones tab is a history of delivery estimates. It differs from a list of standalone milestones: colored series show forecast or actual completion dates for initiatives/ Releases, or for epics beneath a selected initiative. Commitment dates appear as reference lines.

Figure 37. Milestones Timeline with historical delivery observations, current forecasts, and commitment dates.

Step by step

1. Click Milestones with a saved history series available.
2. Leave Root at Project for initiative/Release forecasts, or choose one initiative for its direct epics.
3. Read rows as saved observations, followed by Current.
4. On each row, locate the observation marker and the colored delivery marks for the series in the legend.
5. Read the delivery date from the horizontal calendar axis.
6. Follow a series' trend line across consecutive observations to see how its forecast moves.
7. Compare marks with the vertical goal/deadline references.
8. Hover marks for observation date, estimate date, delivery date, and actual-versus-forecast details. Export for a delivery-trend review.

A mark moving right across checkpoints indicates a later delivery estimate. As delivery approaches, check whether the forecast is stabilizing and how far it remains from the observation date. If the date keeps moving, review Scope and the Delta views to investigate the changes.

Colored marks show delivery dates. Lines connect the recorded forecasts; neither the marks nor the lines represent work duration. There are no readings for days without saved checkpoints. Missing work or missing forecasts can create gaps. A completed item's actual date differs in meaning from an unfinished item's forecast date.

Saved history uses the latest capture per UTC day, while Current remains separate. The Current observation uses the effective live forecast start. If a new edit fails, the view can retain the last successful Current point with a stale-state indication; correct the edit before reporting it as fresh. Root selection is shared with Scope.

To relate scope changes to delivery movement, choose Scope in the Milestones toolbar's View group:

1. Keep the same Root used in Timeline, or select an initiative to inspect its epics.
2. Read absolute delivery dates on the horizontal axis and total estimated scope in hours on the vertical axis. Each initiative or epic has its own colored path.
3. Follow the arrows in checkpoint order. Labels identify saved observations; an outlined diamond identifies Current.
4. Hover for the observation date, delivery date, scope, and any missing-estimate disclosures.
5. Switch back to Timeline to compare dates against snapshot rows, or export the selected presentation with SVG or PNG.

A move up and right means scope grew while delivery moved later. A horizontal move right means delay without net scope growth; additions and removals can still offset each other. Scope includes completed effort and excludes canceled effort, so completing work alone does not shrink it. Missing delivery or wholly unknown scope breaks a path. A partial estimate uses its known subtotal with a disclosure. Identical coordinates share a labeled point. These patterns show association and do not establish which change caused a delay. The presentation choice survives switching diagram tabs during the session.

Figure 38. Milestones Scope presentation relating expected effort to delivery across the Example checkpoints.

24. Team what-if: compare staffing choices

Team what-if runs the same project inputs with Current team and an alternative roster. Compare the results to see how the staffing choice affects forecast delivery.

Figure 39. Current team compared with Without Noa using the expanded Example and current forecast date.

Remove a member temporarily

1. Click Team what-if.
2. Enter a useful What-if team name, such as "Without Noa".
3. Uncheck the member under Use. All current members begin checked.
4. Wait for the alternative forecast to update.
5. Read the project-finish comparison, deadlines met, and earlier/later/unchanged deliverable counts.
6. Inspect individual rows: reference and alternative finish dates, direction of change, and deadline status.
7. Enable Show all deliverables if unchanged results are also needed; the default focuses on shifts and deadline-bearing work.
8. Use Reset to restore current members and clear additions. Check the scenario name separately and change it back if necessary.

Unchecking a member changes only the alternative roster. The committed Team remains the reference. Work pinned to an excluded person is released for reassignment in the alternative; review whether another eligible member can actually take it. If work cannot be scheduled, its result is missing. Do not read that as a zero-day shift.

Add a hypothetical member

1. Click Edit added members.
2. Replace the placeholder name with a unique name for the hypothetical member.
3. Replace the placeholder joining date with an explicit intended start date. Set skills, default daily allocation and any dated overrides, concurrency, speed, and an appropriate location.
4. Wait for validation and the alternative run to update.
5. Use + Add another member for further additions, giving each a unique name.
6. Close the additions editor to give the comparison more space.
7. Review the delivery impact and export the result with Show title enabled.

Every scenario-only added member needs an explicit joining date, including an immediate joiner. Replace both the placeholder name and the placeholder date in the supplied additions template. The what-if simulation gives that person no capacity before the declared start. From that date, it uses their default hours and applicable overrides. This joining-date gate is specific to scenario additions; in the reference Team form, use a zero default and a positive override from the joining date for the same effect.

Existing locations can be referenced. A new scenario-only location can be declared in the additions fragment; it cannot override an existing location's calendar. The untouched placeholder template does not add a person. The structured Team form edits the reference team; the separate what-if additions editor remains a text editor. Correct invalid additions before using the alternative forecast. If you exclude every member and add no capacity, Sundial reports a no-capacity state.

Read calendar warnings before interpreting shifts. If holiday data is incomplete, the comparison marks the dates provisional instead of presenting a staffing improvement as confirmed. Missing or partial delivery on one side is disclosed separately from a zero-day change; resolve the inputs before making a commitment.

Roster search filters visible names without changing the included team. Hover member details to review skills and capacity. Sundial keeps scenario inputs for the session and has no saved named-scenario file format. To keep a record of the comparison, write down the roster assumptions and export an image.

25. Export diagrams and build a report

For an inspection copy of the current project, use Export in the main header:

1. Apply any form drafts whose changes should be included.
2. Choose Export and locate the downloaded project-named YAML file. A connected folder is not required.
3. Keep that file for inspection or sharing a current-state report. It includes work, comments, workflow configuration, Team, sprint records and membership, and Kanban settings.

This export omits native collaboration history, structured project audit history, reporting snapshots, detailed workflow and effort audits, and frozen sprint completion-board payloads. It is not a full backup or a native Open target. Back up the complete .sundial folder for those purposes. No configuration code needs to be copied from this manual.

Export one diagram

1. Open the required tab and wait for its data to be ready.
2. Set root, comparison endpoints, depth/disclosure, counters, assignee display, resolution, or scenario controls as appropriate.
3. Enable Show title. For Delta GANTT, keep Show dates when exact movement is important.
4. Click SVG or PNG in the diagram toolbar.
5. Save the file, or locate the browser download.
6. Open the saved image and check its title, legend, filters, and readability.

SVG preserves vector quality and supported source links. PNG is convenient for a blog, slide, or document. Static exports do not include hover popups or interactive disclosure controls. Exported images include a Sundial caption with the tool's web address; SVG retains the caption's link. Exports include the chart content with its filters applied, regardless of scroll position or viewport zoom. Very large PNG canvases may be uniformly downscaled; SVG retains natural dimensions.

Export a bundle

1. Build a successful current forecast.
2. Select the intended Delta period and history root; prepare the staffing scenario if needed.
3. Use the header's Export SVG or Export PNG.
4. Save the ZIP and confirm the exported diagram count.
5. Extract and review its files before sharing.

The archive includes available current, Delta, history, and scenario charts. Charts lacking their required inputs may not be present; do not assume every archive contains a fixed count. A Team what-if result is included when its chart has been built. Export Sunburst over time separately from its own toolbar to preserve the selected side-by-side comparison. Individual files are named by chart kind, such as wbsTree, gantt, sunburst, workTracker, deltaWbs, deltaGantt, scopeOverTime, milestoneOverTime, and teamScenarioGantt.

A useful review sequence

1. Update the work items, recorded effort, workflow states, priorities, and sprint plan.
2. Review the reference team's calendars and availability.
3. Check Delivery outlook and GANTT for commitments at risk.
4. Compare with the prior checkpoint using both Delta tabs.
5. Inspect Scope alongside Milestones to relate estimate changes to delivery movement.
6. Use Work tracker to investigate capacity or sequencing.
7. Test staffing options if the dates call for a decision.
8. Verify automatic saving, capture the accepted reporting checkpoint, and export the review images.

In the written report, give the reporting start and comparison endpoints. Explain the assumptions and any missing or approximate source data that affect the results. A screenshot of the interface is useful for teaching controls; Sundial's own PNG export is usually better for a chart-only publication.

26. Troubleshooting

Shared editing and planning problems

27. Keyboard and control reference

Sundial intercepts plain Ctrl+S without performing a save. Use Apply to commit a draft and Snapshot to capture a reporting checkpoint.

28. Glossary

29. Further reading

For the project-reporting approach, read Stefano Tommesani's articles on workflow simulation, change reporting, and sunburst project health.

For diagram background, see PMI on work breakdown and scheduling, Asana on Gantt charts, Plotly on sunburst charts, and Plotly on heatmaps.

For collaboration background, see Automerge's local-first overview and concurrent field conflicts. For board context, see Atlassian's Kanban guide.

Screenshots from section 3 onward were refreshed on 22 October 2026 at 1920 × 1080 using the current Example data. The opening and its screenshot are preserved. New captures cover all eleven diagram tabs, Work tracker Capacity mode, PERT estimates, login, and the two Audit panels. Demonstration drafts were discarded; the fresh Example has no committed audit edits.