# Vision by Nano X **The flexible work delivery platform.** Customer guide · October 14, 2026 # Start guide Find the work. Know what matters. Keep delivery moving. Vision is the flexible work delivery platform from Nano X. Bring projects, tasks, customer engagements and operational work into one connected place—and give each team a focused way to work. ## Your first five moves 1. **Start with what needs you:** Open Start here. See your work, ask a question, or jump into a record. Try “Show me my highest priorities today.” 2. **Find your Work Area:** Choose the team or operating space you work in. Its views keep the focus on that area and the folder you select. 3. **Open a project or task:** Check the owner, priority, dates and next action. Open the record to see its context, updates and connected work. 4. **Choose a useful view:** Use a board for flow, Data Grid for details, or Timeline for dates and dependencies. These are views of shared work. 5. **Close the loop:** Record meaningful progress, request a review when required, and leave the next person a clear handover. ## Start with your role - **I’m doing the work:** Use Start here, My Tasks and Heads Up to choose what to move next. → daily-work - **I’m leading delivery:** Connect project health, customer follow-up and team workload. → projects - **I’m setting things up:** Start with access, a Work Area and a small, useful workflow. → administration - **I’m shipping software:** Follow the sprint, task, pull requests and release as one connected delivery story. → engineering ## One record. A clearer path to delivery. A task can appear in your personal work, a project, a board, a timeline and a report. Its identity and history stay connected, so you can change perspective without creating another copy. Follow the example below to see how a request becomes reviewed work and a clear handover. Illustrative example: - **Request — Capture the outcome:** A customer needs a clear onboarding plan. Record the request, the expected result and the person responsible. - **Deliver — Make the next action visible:** Break delivery into useful steps. Connect dates and dependencies so the team can see what must happen next. - **Review — Keep the decision with the work:** The assigned reviewer inspects the evidence and records a response before the configured workflow advances. - **Handover — Finish with an accepted next step:** For an engagement handover, identify the recipient, remaining work and first action. Ownership transfers through explicit acceptance. ## Choose your delivery rhythm - **Plan a sprint:** Set a goal, commit realistic scope and keep changes visible. → sprints - **Run service operations:** Connect incidents, requests, changes and delivery follow-up. → itsm - **Keep customers informed:** Turn current work into a reviewed, shareable dashboard. → reports ## Learn the shape of Vision A Frame is your organization’s boundary. Work Areas create focus inside it. Optional folders organize work, projects hold delivery context, and tasks carry the next action. - Understand the building blocks → concepts - See what makes Vision different → why-vision - Keep important work visible → zombies --- # Why Vision Decades of experience. One connected path to delivery. Vision is built around a practical belief: work becomes easier to deliver when the people doing it can see the whole story. Nano X brings experience from technology, enterprise workflows and customer delivery into a flexible platform that keeps the next action close to its context. ## Built from experience in the work Vision’s product direction is shaped by Eric Karwowski’s decades of experience across technology and customer delivery. His background includes work at Apple, experience with HP, ServiceNow and ClickUp, and study in technology entrepreneurship at Stanford University. That experience informs a practical design standard: make the work easy to find, keep decisions with their evidence, and give teams room to operate differently without losing the connections between them. Experience with large enterprise customers brings a recurring lesson into focus: a powerful platform has to work for the people responsible for the next handover, review or customer conversation. Vision turns those everyday needs into visible workflows. [Eric’s professional background](https://megax.us/about) · [Education background in Eric’s podcast bio](https://podcasts.apple.com/us/podcast/mega-x/id1765077276) ## Global engineering talent. A shared delivery mindset. Nano X brings together top engineering talent from around the globe. That global team brings different perspectives to a shared goal: making complex work easier to find, understand and deliver. The team’s engineering experience complements Eric’s enterprise and customer-delivery background. It shapes how Vision connects a request to its implementation, a review to its evidence, and a release to the outcome the customer needs. ## Keep important work in view Finding a task is only the beginning. Vision connects the signals that help a team decide what needs action: untouched intake in Zombies, priority lanes on a split board, dated dependencies, pending approvals, SLA pressure and cross-project commitments. Consider a support handover that never received a response. Zombies reveals the missing first action; the task preserves the context; the project and timeline show why it matters. The team can make a specific recovery decision instead of treating a populated board as proof that delivery is moving. - See Zombies in action → zombies - Explore split boards → work-areas--split-board - Follow the delivery timeline → projects--timeline ## The moments Vision is built for **Illustrative delivery scenarios** These stories show how familiar delivery problems map to Vision’s capabilities. They are examples of the workflow, rather than named customer case studies. ## Friday: the project is green, but the customer is waiting An engineer records technical progress. A delivery lead sees a healthy project. Yet nobody can quickly say when the customer last heard from the team or what was promised next. Vision tracks the customer-facing touchpoint and its outcome separately from engineering progress. The engagement view makes the missing check-in visible. When ownership changes, the handover carries the remaining work and next action through explicit acceptance. The design lesson: internal activity and customer confidence need separate evidence. Keeping both beside the engagement helps the next person act with context. - Follow customer and engineering progress → engagements ## The code is merged. The delivery is still in motion. A feature spans an API, an interface and a support playbook. One PR merges while another is waiting for review. The project lead needs to understand the outcome without opening every repository conversation. Vision connects those PRs to one task and its release. Required and supporting changes have different roles, readiness shows the remaining review, and the default completion policy keeps verification explicit. The same task can carry the project, sprint and delivery brief. The design lesson: a code event is part of the delivery story. The customer outcome gives it purpose. - See the Engineering screenshots → engineering ## The next project looks small—until you see the other commitments A team member looks available inside one project, but is already committed to two others. Another assignment would make the local plan look complete while putting the wider delivery at risk. Vision’s Bandwidth view brings visible commitments across projects into the capacity discussion. The team can inspect the source work, distinguish booked effort from actual time and agree what should move before accepting more. The design lesson: teams need focus and a wider view of demand. Work Areas supply the focus; connected capacity and reporting supply the perspective. - Understand Bandwidth and capacity → bandwidth ## Spend less effort finding the right work Start here accepts everyday questions and searches the Vision records you can access. Common questions about priorities, zombie tasks and projects behind schedule use recorded data directly. Results link back to the source. Focused Work Areas reduce noise. The global God’s eye views let you look across the current Frame when you need the bigger picture. Search and global views still respect access. - Find answers and work → search ## Make the next step clear Owners, due dates, dependencies, approvals and activity live alongside the work. Configured Work Pack review gates help work move through the agreed process. Engagement handovers keep the outgoing lead accountable until the recipient accepts. The value is a connected path: request → delivery → review → handover. Your team still supplies the decisions and evidence that make the process meaningful. - See connected engineering delivery → engineering ## Flexibility where teams work. Continuity where work connects. Choose Work Area views, add task fields, organize projects and enable relevant Work Packs. One team can manage a delivery board while another works from a grid or sprint rhythm. Configuration changes how people work with the shared engine. It does not require copying the same task into separate departmental systems. Illustrative example: - **Board — See how work is flowing:** Use columns and lanes to inspect status, priorities and the next move. Open a card to work on its original record. - **Data Grid — Inspect and update the details:** Work in compact rows with filters and inline properties. Labels stay compact; task context remains a click away. - **Timeline — See what the dates depend on:** Inspect the delivery sequence. Drag eligible scheduled work, then review affected dates and dependencies before saving. ## Bring planned delivery and service work together A team can plan a sprint, respond to an incident, create a linked follow-up task, review a change and record the time spent—all while keeping the delivery context connected. Service operations and project delivery do not have to become separate islands. Vision fits teams that need both a delivery rhythm and operational accountability. Sprints preserve the commitment, approvals preserve the decision, SLAs expose time pressure, and Briefings make the result understandable to a customer. - Sprints & Cycles → sprints - ITSM & service delivery → itsm - Customer reporting → reports ## From task tracking to delivery context | When the question is… | Use Vision to… | | --- | --- | | “Where is that work?” | Search accessible records and open their context. | | “What happens next?” | Inspect owners, dependencies, reviews and the next action. | | “Have we lost touch with this customer?” | Check customer contact separately from engineering progress. | | “Can this person take more work?” | Review visible commitments across projects, then inspect hours and bookings. | | “Can another team work differently?” | Give it focused views and appropriate Work Packs on the same work engine. | ## Useful by design, without inflated promises Vision is designed to reduce navigation and repeated setup. We do not claim a measured speed advantage over another platform. Workflow behavior depends on configuration, permissions and the records your team maintains. Core search answers, engagement checks, views and reporting do not need a model call. Optional AI assistance is available with the required access, provider connection and administrator budget. --- # How Vision fits together A shallow structure. Plenty of room to work. Start with an organization boundary and give each team a focused home. You do not need a deeply nested folder tree to make work understandable. ## From Frame to task - **Frame:** Your organization’s boundary for people, access, integrations and settings. - **Work Area:** A focused operating space for a team, department or type of work. - **Folder:** Optional organization inside a Work Area. Folders are one level deep. - **Project:** A delivery outcome with owners, dates, health and connected work. - **Task:** An actionable work record with its own status, context and history. ## Focus locally. Look across when needed. A Work Area’s horizontal views follow its scope. Select a folder to narrow the view. Top Level returns to the current Work Area’s overview. God’s eye is the global view across accessible work in the current Frame. It does not span other customer Frames or reveal private records. ## Connect without copying Tasks can connect to projects, documents, milestones, dependencies and supported external tools. Accessible references can cross Work Areas without duplicating records or widening access. Tasks and documents can also live directly in a Work Area or folder. A project is useful when you need shared delivery context; it is not mandatory for every piece of work. --- # Your daily workspace Three starting points for a focused day. Start here helps you orient. My Tasks holds your personal work. Heads Up brings attention back to the things that need a response. ## Start here Review what needs you, what is up next and what has been completed. Ask a question or use search to open the relevant record. Authorized users can switch between My work and My team. Your default page is a personal setting. An explicit link to a task or project still takes you to that destination. ## My Tasks Use My Tasks to focus on your work. Confirm owner, priority and due date before deciding what to do next. Personal tasks and shared project tasks serve different purposes; choose the right scope when creating work. If a legacy assignment cannot be confidently matched to an account, Vision may identify it as needing confirmation rather than guessing who owns it. ## Heads Up Review assigned work, approvals and followed-task updates. New @mentions can bring a permitted recipient back to the relevant work. Engagement obligations appear for named leads, handover recipients and reviewers. Type @ in a supported task description or comment to choose a person from suggestions. Mentioning someone does not give them access to private work. ## A practical daily rhythm 1. **Choose:** Find the highest-impact work you can move today. 2. **Check:** Read the current record, dependencies and outstanding decisions. 3. **Act:** Do the work and update the shared record with the meaningful result. 4. **Hand over:** Make the next action and its owner explicit. ## Look for the work that needs a response Include Zombies in your daily review of new work. Then inspect priorities, overdue work, blocked items and outstanding reviews for work already underway. These signals complement each other; none replaces the next recorded action. - Build an important-work review → zombies--daily --- # Find work & answers Ask naturally. Follow the evidence. Use Start here to ask common work questions or search across accessible Vision records. Open a result to continue in the original record. ## Try a practical question These questions use Vision’s recorded work and confirmed identity. A useful answer may explain that no matching records were found or that assignments need confirmation. It should not invent missing information. - Show me zombie tasks - Show me what I need to work on - Show me my highest priorities today - Show me my projects that are behind - What zombie tasks mean → zombies ## What search can see Search spans supported records you can access, including work, projects, documents and approved custom-field or engagement context. Ordinary search is broader than the My work summary. Explicit “my” or “my team” questions retain that personal or team scope. Search does not automatically crawl the web, every connected MCP tool or the contents of arbitrary binary attachments. A hidden record remains hidden. ## When AI helps If a deeper question needs it, Start here can use a configured Claude or OpenAI provider within the administrator’s allowance and required XOS access. Answers use bounded relevant context and link to their sources. Missing provider setup, unavailable evidence or a budget limit produces an explanation and useful next steps. Typing in the box and common built-in answers do not trigger a model call. - Understand AI and automation → ai --- # Work Areas & views The same work, with the right field of view. A Work Area can contain projects, tasks, folders, docs and optional views. Make it a useful home for the team that works there. ## Move around a Work Area 1. **Open the Work Area:** Choose it from the sidebar. Use the location chooser to move into a folder or back to Top Level. 2. **Choose a view:** Overview, Projects, Work and Docs are the starting points. Add the optional views you use most. 3. **Keep useful tabs:** Add views such as Data Grid, Calendar, Reports, Bandwidth, Sprints & Cycles, Engineering or Packs. Available options depend on access. ## Keep or remove views Optional tabs stay in your personal bar for the Work Area or folder on this device. Save view captures a named personal view with supported filters. Delete a saved view or remove a tab when it is no longer useful; the underlying work remains. Shared Board/List views use their own sharing and ownership controls. A personal saved view should not be mistaken for a shared team configuration. ## Split the board to see what matters A single board can answer two questions at once. Columns show Status, Owner or Due date; horizontal lanes separate another dimension, such as Priority or Project. You can see important work in context without copying it into another board. 1. **Open a board:** Choose Board view for the work you are inspecting. A Work Area keeps the starting scope focused. 2. **Choose the columns:** Use Group, or Columns in Split & display, to select Status, Owner or Due date. 3. **Add the second perspective:** Open Split board and choose Assignee, Project, Team, Priority, Work Area or Folder. Choose None to return to one lane. 4. **Keep the board readable:** Set Compact or Comfortable cards and choose the fields that help the team decide. Open a card to update its original record. | Combine | Answer | | --- | --- | | Status columns + Priority lanes | Which high-priority work is waiting, moving or under review? | | Owner columns + Priority lanes | Who owns the urgent work, and what else sits beside it? | | Status columns + Project lanes | Where is each project’s work slowing down? | ![Vision shared board split into Urgent and High priority lanes with Alex Morgan as the owner column and the same task and bug records visible.](assets/split-board.jpg) Split board · synthetic demo. Owner columns and Priority lanes separate urgent follow-up from high-priority delivery while preserving the same records. - Understand task workflow → tasks - Check the person’s wider commitments → bandwidth ## Make the space recognizable Authorized owners can choose a built-in Work Area icon by clicking the icon beside its name. Search the icon chooser or restore the default globe. Double-click the name or description to edit it when authorized. Keyboard and actions-menu alternatives keep these controls available without permanent edit buttons. ## Know what stays connected A scoped view narrows the work you are inspecting. Bandwidth still considers the person’s other visible commitments so a project filter does not create false availability. Packs belong to a Work Area. Opening a pack from a folder returns to the Work Area’s scope. --- # Tasks & workflow Give every next step a clear home. A task connects the action to its owner, dates, discussion, evidence and delivery context. Open it from a list, board, grid or report to work with the same record. ## Create a useful task 1. **Name the outcome:** Use a title someone can understand without opening the description. 2. **Add context:** Explain the result you need, attach or link useful evidence, and identify the next action. 3. **Assign and schedule:** Choose the responsible person or team, priority, project when useful, and a realistic due date. 4. **Connect the work:** Add subtasks, document references, milestones or dependencies where they clarify delivery. ## Turn a task into a bug—or a bug into a task **Work Pack and service-controlled records may lock their type. Follow that workflow rather than trying to reclassify a controlled service record.** An investigation may uncover a defect. A reported bug may turn out to be ordinary delivery work. Change the classification on the existing record so the team keeps its context, ownership and history together. 1. **Open the work record:** Open the task or bug from a board, list, search result or project. 2. **Open Classify work:** Click the small work-type icon immediately beside the identifier in the record’s top bar. This is separate from the decorative icon beside the title. 3. **Choose Bug or Task:** Select Bug to classify a defect, or Task to return to ordinary work. The displayed identifier changes between BUG and TSK while the underlying record stays the same. 4. **Check the next action:** Review priority, ownership and workflow status. The classification change is recorded in Activity; it does not resolve the issue or create a second task. ![Vision task header with the Classify work menu open, showing Task, Issue, Bug, Feature and Decision choices beside the existing record.](assets/task-bug-conversion.jpg) Task → Bug → Task · synthetic demo. Use the small type icon beside the identifier to reclassify the existing work. - Connect the fix to code and release → engineering - Recover untouched work → zombies ## Move work with evidence Use the status that reflects the actual work. Configured workflows may require approval or completion evidence before a task can advance. A status change should not stand in for a missing decision. Use comments and @mentions for collaboration. Keep changes and decisions in the record so the next person can understand what happened. ## Add the details your team needs Labels support lightweight categorization. Custom fields capture structured information such as a customer reference, acceptance date or check. Owners and Admins manage task definitions in Field Library; permitted task editors fill the values below Activity. Track time from the task when needed. Time permissions and invoice locks still apply even if you can open the task. - Fields and configuration → fields - Time and billing foundations → time --- # Projects & timelines Connect outcomes, dates and day-to-day work. A project brings owners, health, milestones, work, documents and updates together. Use its Overview, Work, Timeline and Updates views to move between context and execution. ## Set up a project for clarity 1. **Define the outcome:** Describe what this project should deliver and how the team will recognize completion. 2. **Confirm ownership and access:** Choose the lead and relevant people or teams. Access follows the existing Frame and container rules. 3. **Connect the plan:** Add dated work, milestones and dependencies. Keep reported progress and project health meaningful. 4. **Post updates:** Record completed work, next steps and risks so others do not need to reconstruct progress from task changes. ## Move a date. Review the delivery impact. **Moving work earlier does not automatically pull successors earlier. Started, closed or controlled work is not automatically shifted. Dates use calendar days; this is not a working-day or critical-path scheduler.** A project timeline makes the sequence visible: tasks, project dates, milestones and dependencies. When a date changes, Vision can show the affected work before you commit the move. This helps the team discuss the actual consequence of a delay. 1. **Open Timeline or Gantt:** Expand the relevant project and find its scheduled task, project bar or milestone. 2. **Propose the move:** Drag horizontally to a new date. A regular click opens the item; Link tasks mode is for relationships. 3. **Review related dates:** Inspect the old and proposed dates, including accessible affected records outside the current view. Eligible downstream work can move forward to satisfy finish-to-start dependencies. 4. **Confirm or cancel:** Save the reviewed change, or cancel without changing dates. Use the outcome in your project update and discuss any remaining conflicts. ## Make dependencies explicit Use Link tasks to add dependencies. A normal drag proposes a date change; link mode changes the relationship. Review conflicts rather than assuming every connected item can move. Use the project’s Capacity view to inspect visible commitments across projects before adding more work to a person. - Check Bandwidth → bandwidth ## Use the timeline as a conversation Before a release review, look at the next milestone, the work it depends on and the person who owns each next action. If a dependency moves, explain the effect on delivery before simply changing the target. Use project health and Updates alongside the timeline. A tidy schedule is useful only when it reflects the actual work and the unresolved decisions. - Plan the next sprint → sprints - Keep neglected work visible → zombies --- # Sprints & Cycles A clear goal. A realistic commitment. Room to learn. Vision brings the sprint goal, committed work, capacity, documents and review into one operating view. Teams can focus inside a Work Area while leads inspect delivery across the accessible Frame. ## Choose the rhythm that fits Use a Sprint when the team needs a goal, an explicit commitment and a planning, daily check-in, review and retrospective rhythm. Use a Cycle for a lighter repeating focus window. One- and two-week cadences are supported. Open Sprints & Cycles from God’s eye for a broader perspective, or add it as a focused Work Area view. The sprint stays connected to its original tasks and projects. ![Vision sprint operating view with a customer onboarding goal, committed tasks, capacity and planning controls.](assets/sprint-operate.jpg) Sprint operating view · synthetic demo data. ## Plan around the goal and the real capacity Sprint estimates and capacity are planning units, not billable hours. The interruption reserve reduces the capacity available for planned delivery; it is not a time entry. 1. **Define the outcome:** Give the sprint a meaningful name, owner, dates and a goal the team can assess. 2. **Select ready work:** Choose the backlog items that serve the goal. Confirm owners, dependencies, estimates and useful documents. 3. **Check the whole workload:** Use Bandwidth to inspect visible commitments across projects. Set sprint capacity and an interruption reserve for operational work. 4. **Start the commitment:** Starting captures the committed scope. The baseline makes later changes visible instead of rewriting the original plan. - Check cross-project capacity → bandwidth ## Run the sprint where the work lives Dashboard, Operate, Calendar and Reports offer different perspectives on the same sprint. Delivery signals surface blocked work, incomplete estimates, capacity pressure and progress against the plan. They are prompts to inspect evidence, not promises of an outcome. | Moment | What to do in Vision | | --- | --- | | Planning | Agree the goal, owners and scope; keep the delivery brief close. | | Daily check-in | Inspect blockers and owner updates, then open the actual task to act. | | Review | Demonstrate completed outcomes and record the evidence. | | Retrospective | Capture improvements and turn the next action into owned work. | ## Make interruptions a conscious decision An addition to an active sprint needs a written reason. Vision creates a leadership review request; the item stays outside the commitment until an authorized leader approves it with a note. The decision and scope change remain recorded. This matters when the same engineers handle customer delivery and service follow-up. Urgent work can be considered without silently pretending the original commitment never changed. - How the approval engine works → reviews - Connect incident follow-up → itsm ## Close with an outcome Review completed work, remaining scope and the reason for spillover. Close the sprint with its outcome and make the next destination for unfinished work explicit. Completed sprint history preserves the result for later review. Vision supports the team’s delivery practice. Clear goals, honest estimates, useful reviews and good decisions still come from the team. Core sprint metrics do not require AI tokens. - Engineering & connected delivery → engineering --- # Engineering & connected delivery Connect the sprint, the code and the release to the work they deliver. The code tells you what changed. Vision keeps it connected to why it matters: the project, sprint, task, review and release. Engineers and delivery leaders can follow the same work from a planned outcome to evidence of delivery. ## One outcome. A connected delivery story. Imagine a customer onboarding improvement. It belongs to a project, is committed to a sprint and needs an API change, an interface change and a support handover. Vision keeps those relationships around the task, even when implementation spans several pull requests. Open Engineering from God’s eye for accessible work across the Frame, or add it as a Work Area view for a focused team context. The underlying records stay connected. | Follow the connection | What it answers | | --- | --- | | Project → sprint → task | Why are we doing this, who owns it and what did we commit to? | | Task → repository → pull requests | Which code changes implement the outcome, and what needs review? | | Pull requests → checks → delivery chain | What is ready, what is blocked and which changes are required? | | Linked work → release → saved notes | What is in the release, where is it going and what should people know? | | Delivery → report → next action | What can we show stakeholders, and what still needs follow-through? | ## See code review in its delivery context The Pull requests view brings repository, branch, checks, review state and Vision links into one place. Search by title, number, branch or author, then inspect a PR to see the work and releases it connects to. A detected stack shows dependent PRs together. Read the blocker before assuming passing checks mean the work can ship. Detailed code review, branch protection, conflict resolution and merging remain in GitHub. ![Vision Engineering with a synthetic onboarding pull request stack, checks, review states and links to the same task and release.](assets/engineering-pull-requests.jpg) Engineering · synthetic demo data and simulated GitHub responses. Each PR connects to the same delivery work and release. ## Keep every pull request attached to the outcome The task brings code context beside its owner, project, documents, time and activity. You can answer “What is this change for?” without reconstructing the story from separate conversations. 1. **Connect the repository:** An authorized member connects GitHub and chooses a repository they can access. Confirm the repository and branch on the task. 2. **Carry the Vision ID:** Include the immutable task ID in the PR title, description, branch or commit. Vision can also use an explicit PR link or a linked Copilot artifact. 3. **Review Code and delivery:** Inspect the PR chain, branch relationships, checks and review state. Choose a primary PR for the task’s main GitHub link. 4. **Separate required and supporting work:** Required PRs form the delivery completion gate. Supporting PRs remain useful context without holding that gate. ![Vision pull request inspection connects the onboarding change to its task, delivery brief and release, with checks and the outstanding review visible.](assets/engineering-context.jpg) Connected PR context · synthetic demo. One inspection opens the task, its delivery brief or its release; passing checks still leave a reviewer decision outstanding. ## Merged is a milestone. Delivered is an outcome. Vision records GitHub signals and can move eligible work into In progress or In review. The task’s activity provides the reason for the change. A required PR that is still open keeps the delivery chain incomplete. Verified outcome is the default completion policy. After all required PRs merge, verify deployment and the customer result before marking the work Done. Teams can explicitly choose On merge when that is the appropriate completion rule. Readiness depends on the current GitHub evidence and policy result. Missing or stale evidence is not proof of a passing gate. GitHub remains the authority for whether a PR may merge. ## Carry the work into the release In Engineering → Deployments, create a release record or import an available GitHub release. Attach the work being delivered, set the environment and target, and save release notes. The release can show PR readiness derived from its linked work. Keep the rollout, verification and support tasks linked so a release has an understandable delivery history. Saved note versions and activity help the next person understand what changed. A Vision release record coordinates the release. Changing its status or evidence percentage is not proof that an external deployment ran successfully; check the deployment result and record the outcome. ![Vision release record for a synthetic customer portal showing linked onboarding and verification tasks and the readiness of three pull requests.](assets/engineering-release.jpg) Release context · synthetic demo. The release’s selected tasks and their PR readiness remain connected. This focused capture shows the same onboarding work and verification task. ## Connect engineering to the rest of delivery These are connected views and records with distinct responsibilities. Merging code does not acknowledge an On-call incident, satisfy an approval or prove that a customer has been contacted. Close each loop explicitly. - **Plan the sprint:** Commit the work, manage changes to scope and review the outcome with the team. → sprints - **Review and approve:** Bring the right decision-makers into the workflow and keep their decisions recorded. → reviews - **Close the service loop:** Connect incident or change follow-up to delivery work when the ITSM modules are enabled. → itsm - **Show stakeholders the result:** Publish a reviewed customer dashboard snapshot with selected project progress and next actions. → reports ## Make the delivery pattern reusable The Agent engineering delivery Work Pack provides a repeatable sequence from specification and planning through implementation, automated verification, opening a PR, human review and merge. Dependencies, acceptance criteria and evidence stay attached to the generated work. Use the pack to agree the process and handover. AI execution is optional and depends on configured providers, permissions and budgets; adding the pack does not automatically run an agent or deploy software. - Work Packs → packs - Integrations & connected tools → integrations - AI assistance and controls → ai --- # Zombies & important work Notice the work that never received a first response. A task can have a title, an owner and a due date—and still receive no action. Vision’s Zombies view surfaces eligible new work that has passed its intake window untouched, giving the team a clear place to recover it. ## An early warning for a missing first step Imagine a release depends on confirming the support owner. The task was created four days ago, assigned and marked urgent, but nobody recorded a first action. A project can look organized while that handover remains unclaimed. Zombies brings that untouched item back into view. The team can inspect its age, clarify the next action and start triage before the gap becomes a customer problem. This is an illustrative workflow, not a measured customer outcome. ![Vision Zombies queue showing a four-day-old urgent support-owner task with project context and the Revive and start triage action.](assets/zombie-triage.jpg) Zombie triage · synthetic demo. An urgent handover task has had no first recorded action; its age and recovery action are visible together. ## Understand what the signal means Simply opening an item does not acknowledge it. Creation, import and routine automation entries do not establish that someone has acted on the work. Zombies is an intake signal. It does not continuously re-age every task after it has received a meaningful action, and some controlled Work Pack records are exempt. | Signal | Meaning | | --- | --- | | New | Eligible work is waiting for its first recorded action. | | Zombies | Untouched new work has passed the configured intake window. The default is 72 hours; applicable administrator rules can change it. | | Revive & start triage | Acknowledge the item and return it to the appropriate workflow status so triage can continue. | | Important work already underway | Use priorities, due dates, blocked-work signals, reviews and SLA attention to monitor it. | ## Recover the work deliberately 1. **Find it:** Open All Activities → Zombies, or ask Start here “Show me zombie tasks.” Search and filter the accessible results. 2. **Read the context:** Check age, priority, project and ownership. Confirm whether the need still exists and what is blocking a first response. 3. **Revive and start triage:** Use Revive & start triage when you are ready to acknowledge the item. Existing history remains available. 4. **Record the actual next step:** Assign the right person, agree a useful date and record the result or decision. Reviving a task is not the same as completing it. ## Make important work a daily habit 1. **Start with the decision:** Ask “Show me my highest priorities today” and inspect the source records. 2. **Check the blind spot:** Review Zombies for important work that never received its first action. 3. **Check work in motion:** Review overdue or blocked work, pending approvals and SLA pressure. 4. **Check delivery consequences:** Follow project dependencies, confirm capacity and record a clear next action. - Start here and search → search - Use split boards for priorities → work-areas--split-board - Approvals & escalations → reviews - SLA targets & timers → sla --- # Customer engagements Customer contact and engineering progress are two different signals. Use Projects → Engagements to see which customers need attention, when meaningful contact was recorded, and whether engineering progress and handovers are current. ## Establish the operating rhythm 1. **Name the leads:** Assign customer and engineering leads plus an escalation reviewer from people with project access. 2. **Set the cadence:** Choose independent customer-contact and progress deadlines. Defaults are seven calendar days. 3. **Record the evidence:** Log a customer-facing call, meeting or message with an outcome and next action. Record engineering progress separately. ## Make follow-up meaningful An unanswered attempt is different from a completed customer interaction. Editing a task, importing a record or posting an ordinary comment does not reset either check-in clock. Use the dashboard to find overdue contact, missing progress, blocked work and handovers awaiting action. Counts open their matching records. Heads Up shows obligations to the relevant people. ## A handover ends with acceptance Record scope, completed and remaining work, risks, dependencies, evidence and the first next action. Choose the receiving person and an acceptance deadline. The outgoing engineering lead remains accountable until the recipient accepts. Requested changes require resubmission; a missed deadline raises attention rather than silently transferring ownership. ## Keep the record honest Contact and progress are recorded by your team. Vision does not infer a customer conversation from email activity or automatically read every message. Imported ownership may need mapping before check-ins can begin. - Bring existing engagements into Vision → imports --- # ITSM & service delivery Service operations connected to the work that fixes them. The optional ITSM Pack brings incident, request, problem and change management into Vision’s shared delivery environment. Service teams keep their own queues while engineering follow-up remains connected to projects and tasks. ## Start with the service modules you need | Module | Use it for | | --- | --- | | Incident management | Restore interrupted or degraded service and track the response. | | Service requests | Handle fulfillment work and supported service-catalog requests. | | Problem management | Investigate recurring issues and retain the underlying cause and follow-up. | | Change management | Review planned change with implementation, approval and service context. | | CMDB | Link configuration items and their relationships to the affected work. | ![Vision Change management overview showing open service work, urgent work, SLA status and a synthetic change record.](assets/itsm-overview.png) ITSM module overview · synthetic demo data. This demo uses the configurable pack name “Service Hub”. ## From an incident to a durable improvement The incident and its delivery task have different purposes. Resolving the incident does not mean every improvement task is complete. The relationship lets the next person follow the context. 1. **Capture the service context:** Record the impact, priority, owner and relevant service or configuration item. 2. **Respond and coordinate:** Use the incident record, work notes, escalation and On-call where enabled. 3. **Connect the follow-up:** Create a linked Vision task when the investigation needs engineering delivery. Keep its owner and due date explicit. 4. **Review and resolve:** Use the appropriate approval and change workflow, record the outcome and retain supporting knowledge. ## Bring service context into delivery decisions Search configuration items by name or identifier instead of scrolling a long list. Linked service context helps a reviewer understand what a change could affect. A follow-up task can participate in a project or sprint through the normal workflow. Active-sprint scope controls still apply; creating an incident does not automatically expand the team’s commitment. - Sprints & Cycles → sprints - Approvals & escalations → reviews - SLA targets & timers → sla - CMDB & change context → cmdb ## Enable deliberately An Owner or Admin configures Administration → Work packs → ITSM Pack and chooses the available modules. The display name can match the team’s language. Module access depends on the Frame’s paid grants; ITSM and CMDB are separately controlled. Turning a module off retains its records while hiding its navigation and blocking its service actions. Re-enabling an authorized module restores the retained work. Access to private records is still enforced. --- # CMDB & change context Connect service records, dependencies and change history. CMDB Lite gives configuration items a useful home beside the work that affects them. Record the system, its owner and lifecycle, then connect related tasks and change context so a reviewer can understand the impact. ## Keep the inventory useful 1. **Enable the right module:** An authorized administrator enables CMDB in the ITSM Pack. The relevant paid add-on grant and access are required. 2. **Describe the configuration item:** Record a clear name and type, then the useful owner, team, vendor, support, location and technical details. 3. **Maintain its lifecycle:** Use Development, Active, In storage or Retired to reflect its current state. 4. **Find the right item:** Search instead of scrolling the inventory. Use type, lifecycle and owner filters, or switch between Dashboard, Table and Cards. ## Connect the affected work Record the upstream and downstream dependency context that helps people understand the service. Search and link existing tasks to keep investigation, maintenance and delivery follow-up attached to the configuration item. For example, a sign-in defect may depend on an identity service. Linking the bug and recording that relationship helps the reviewer connect the customer symptom to the system being changed. The example does not imply automated discovery of your infrastructure. - Classify a task as a bug → tasks--convert - Connect engineering evidence → engineering ## Record the impact before the change 1. **Open the configuration item:** Confirm that it is the correct system and inspect existing dependencies and linked work. 2. **Record the change:** Use + Record change to enter the summary, dependency impact, outage risk, affected dependencies, effective date and notes. 3. **Review the history:** Use the recorded assessments and change history to understand what was known and what happened. 4. **Follow the required approval path:** Use the configured Change management or approval workflow when a decision is required. A CMDB assessment itself does not approve or execute a deployment. ## Keep access and control explicit CMDB and service records remain subject to their existing Frame and record access. Linking them into delivery does not widen access. Disabling the module retains records while removing its active navigation and actions. The current dependency context is maintained by people. CMDB Lite is not an automatic infrastructure discovery, network enforcement or deployment engine. - ITSM & service delivery → itsm - Approvals & escalations → reviews - On-call response → oncall --- # Approvals & escalations Put the decision, evidence and accountability in one place. Vision’s approval engine keeps a request and its decision together. Assigned reviewers, required explanations and retained history make the next step clear across delivery, service work and configured workflows. ## Follow the decision from request to outcome 1. **Submit the request:** Describe the decision needed and link useful evidence. The request begins Pending with the submitter and submission time recorded. 2. **Route to the right reviewer:** Configured routing and reviewer assignments determine who may decide. Being able to view the record is not permission to approve it. 3. **Record the decision:** An authorized reviewer approves, requests changes or declines. Declines and requests for changes require an explanation. 4. **Respond and resubmit:** The original submitter can return declined work or requested changes for review with a note explaining what changed. Earlier decisions remain in the history. ![Vision approval detail showing the release-readiness request, assigned decision context and submission history.](assets/approval-review.jpg) Approval review · synthetic demo data. ## One decision history, several delivery contexts Use approvals for supported service decisions, configured Work Pack review gates and sprint scope requests. Each workflow retains its own authorized reviewers and transition rules. For example, a sprint addition stays out of committed work until leadership approves it. A configured pack stage can require a review before its workflow advances. A generic approval is not a blanket authorization for every linked action. One assigned authorized reviewer can decide a shared-work request. Do not assume this means unanimous approval, sequential committee review or an electronic-signature contract. ## Keep the evidence trustworthy The decision records who acted, when and the required response. A completed decision cannot be rewritten through an ordinary record edit, and requests are retained as audit records. Review the actual record and current evidence before deciding. For a changed request, explain the change and use the supported resubmission path. ## Escalate when a decision needs attention Raise an escalation with the delivery issue, context and outcome you need. The Escalations view brings unresolved work and recorded history together so leads can act on the source. An engagement attention flag or Heads Up obligation does not automatically create an Escalations record. Use the explicit escalation action when that is the desired workflow. - SLA targets & timers → sla - Work Packs → packs --- # On-call scheduling Know who is covering, where the gaps are and what happens next. Vision On-call combines the schedule, response queue, handovers and linked follow-up. It helps teams plan coverage and keep incident response attached to the work. ## Build a schedule people can read Week, two-week, month and three-month zooms help you inspect different horizons. Shift details preserve exact times and the display timezone. Rotation intervals use elapsed hours, so daylight saving can change the local handoff time. 1. **Create a rotation:** An Owner or Admin chooses the team or project scope, eligible responders, shift length and start. 2. **Assign the roles:** Set primary and backup responders, with optional shadows. Confirm the acknowledgement window and routing policy. 3. **Inspect the schedule:** Use the timeline, zoom, date navigation, timezone, search and My shifts filters to inspect the relevant coverage. 4. **Resolve the gaps:** Review missing primary or backup cover and overlapping duty before relying on the schedule. ## Adjust one shift without rewriting the rotation Use temporary cover or an assignment edit for the selected person, role and time window. Include the reason. Arrange shifts lets an admin drag an eligible primary or backup assignment, review the proposed move and save it. Moving an assignment does not move the repeating roster. Vacated time becomes an explicit gap to resolve. Canceling the editor leaves the saved schedule unchanged. ## Plan coverage alongside delivery capacity Before assigning a shift, inspect the person’s existing delivery workload in Bandwidth. Before committing more project work, inspect their On-call duty for the same period. This keeps service responsibility in the capacity conversation. Coverage, assignment counts and booked hours remain distinct. Reserve expected interruption capacity in the sprint or maintain the relevant bookings; a duty shift does not automatically reduce Scheduled capacity. - Use the combined planning workflow → bandwidth--coverage ## Move from coverage to response Route an accessible incident to On-call manually, or use explicitly enabled automatic routing for eligible high-priority incidents. Responders can acknowledge, escalate to backup, snooze with a reason or hand off with a note. Acknowledgement stops the response escalation clock; it is not incident resolution. Create a linked task with an owner and due date when follow-up needs its own delivery path. Review Handoffs & history for the recorded sequence. ## Connect the channels you actually use Project-linked Slack or Microsoft Teams destinations can receive configured notifications. Provider acceptance is not proof that a person has read or acknowledged the incident. The Vision response queue remains the place to confirm response state. Calendar export is a downloadable schedule snapshot. On-call is a separately granted add-on; it does not include SMS, voice calls or native emergency push alerts. - ITSM & service delivery → itsm - Check cross-project workload → bandwidth --- # SLA targets & timers See the deadline without losing the work’s actual status. Vision places service-level timing beside the work. A visible target, remaining time and breach state help teams decide what needs attention and keep the response traceable. ## Set a meaningful target 1. **Open the relevant work:** Confirm the owner, priority and deadline. A due date alone is not proof that an SLA timer has been started. 2. **Start the SLA:** Use the task’s SLA controls to set the supported duration and start the timer. The work’s due date and time provide the deadline. 3. **Inspect the condition:** Look for Running, Paused, Met or Expired, alongside remaining time or time past target. 4. **Act on the source:** Coordinate the response, update the record or escalate the need. A dashboard signal should lead back to the actual work. ## Pause, resume and finish explicitly Authorized task editors can pause and resume the timer. Pausing preserves the remaining time; resuming sets a new deadline from that remaining duration. These actions are recorded in activity. Mark the target met when the work satisfies it. Stopping a breached SLA keeps the breach visible; it does not turn a missed target into a success. Starting a new SLA is a separate action. ## Keep service timing separate from workflow progress A task can be In progress or In review while its SLA is breached. Vision preserves the workflow status so the team can continue moving the work without concealing the missed target. Service-module overviews and escalation reporting expose relevant SLA attention. On-call acknowledgement timing, project targets, engagement check-ins and task SLAs are distinct clocks; one action does not satisfy them all. ## Agree the policy before relying on it The task SLA is a deadline-based elapsed-time control. Do not assume it applies business calendars, holidays, contractual exclusions or a full entitlement engine. Define the team’s operational policy and use the supported controls consistently. - Approvals & escalations → reviews - On-call response → oncall --- # Bandwidth & capacity A quiet project does not mean a person is free. Bandwidth helps you inspect visible assignments across projects. Local filters focus the view without discarding the other commitments you are allowed to see. ## Check before assigning 1. **Find the person:** Open Bandwidth or a project’s Capacity view. 2. **Inspect their visible workload:** Compare the work in the current view with their other visible assignments. 3. **Open the sources:** Inspect the actual tasks behind a count to understand urgency, effort and blockers. 4. **Check scheduled hours:** Use bookings, working schedules and leave where available before treating a person as available. ## Read the numbers correctly A task count is not an estimate of hours. A booking is scheduled demand; it is different from logged time or remaining effort. Missing bookings and inaccessible work prevent a guaranteed availability claim. Direct and team assignments are considered together so the same record is not counted twice for the same person. Opening a task keeps the source context available. ## Use the context to make a decision Discuss the tradeoff, adjust the schedule or reassign work with the responsible people. Bandwidth supports the decision; it does not silently redistribute commitments. ## Check On-call before committing more work **On-call duty does not automatically subtract hours from Scheduled capacity. That calculation uses working schedules, time off and recorded bookings. Task counts and duty assignments are context, not a guarantee of free time.** An engineer may have room in one project and still carry commitments elsewhere—or be covering service response. Bandwidth’s wider workload and On-call’s duty schedule answer different parts of the same planning decision. 1. **Inspect cross-project commitments:** Open Bandwidth and inspect the person’s visible assignments. A focused project or Work Area should not be treated as their whole workload. 2. **Review duty coverage:** Use the On-call shortcut to inspect the schedule, responder coverage and handovers for the same period. 3. **Allow for interruptions:** Adjust the delivery commitment, recorded bookings or sprint interruption reserve to reflect the operational load you expect. 4. **Revisit the plan:** After an incident, review follow-up work and update the actual bookings, sprint scope or project dates that changed. - Plan On-call coverage → oncall - Make sprint interruptions visible → sprints--scope --- # Reports & shared briefings Understand the source. Share the right snapshot. Reports help you inspect accessible work and open the records behind the numbers. Briefings turn a reviewed selection into a sharp HTML dashboard for customers or stakeholders. ## A customer-ready view of delivery Share a coherent picture of selected projects: delivery totals, completion over time, current work status, reported project progress and overdue next actions. Where engagement check-ins are configured, customer contact and engineering progress remain separate signals. The actual shared page is HTML with sharp text and SVG charts. Choose Aurora, Ocean or Sunrise for restrained gradient accents over the dark layout. The preview and published page use the same renderer. ![Dark Vision customer briefing for four synthetic projects, with delivery totals, completion chart, status distribution, portfolio progress and overdue actions.](assets/customer-dashboard.png) Customer dashboard · synthetic demo data only. No live engagement records are included. ## Create a briefing 1. **Open Reports → Briefings:** Choose accessible projects from the current view. 2. **Set the context:** Add a title, choose a 7-, 30- or 90-day reporting period and select a palette. 3. **Review the preview:** Inspect project progress, work status, overdue actions and recorded check-ins. Missing data stays explicit. 4. **Choose how to share:** Use named signed-in recipients or, when authorized, an expiring link for anyone who has it. ## Know what the link shares A briefing is a reviewed snapshot, not a live synchronized dashboard. Refresh and publish a new link to share updated data. Links can expire after 1, 7 or 30 days and can be revoked. Named recipients need an active account in the same Frame and current source access. Public-link publication is an Owner/Admin action and excludes private sources. A downloaded copy cannot be recalled. ## Keep the numbers meaningful Reported project percentage is different from the share of tasks completed. Cancelled work is not delivered work. Customer contact and engineering progress have separate dates. Use source links inside Vision to investigate a result before making a delivery decision. - Customer engagement signals → engagements ## Readable on the customer’s screen The layout adapts to narrower screens. Dense chart and table regions retain their labels and can scroll within their own area. Customers can read the shared snapshot without installing Vision. For a weekly review, choose the relevant projects and period, inspect missing information, then publish the reviewed snapshot. Use a fresh preview and link for the next review. ![Vision customer briefing at a narrow screen width, with stacked delivery metrics and a completion chart.](assets/customer-dashboard-mobile.png) The same dashboard at 390px · synthetic demo data. --- # Work Packs Give each discipline a workflow that fits. Functional packs describe what a team does. Industry packs adapt the operating context. Both use Vision’s shared work engine, so teams keep the same records, access controls and history. ## Choose a useful starting point Examples include Marketing, Engineering, Finance and accounting, Customer success and Professional services. A pack can supply typed intake, fields, stages, focused views and an assigned-reviewer workflow. A pack is not a claim that Vision includes every specialized industry system. For example, a Finance workflow is not a general ledger, and a Professional services workflow is not a full customer-billing engine. ## Configure before activating 1. **Choose the Work Area:** Open Work packs in Administration or the authorized Work Area setup. 2. **Review the configuration:** Set the display name, fields, reviewers and relevant controls. Installation creates configuration, not sample work. 3. **Save and preview:** Validate the draft and inspect its effect before publication. 4. **Activate:** Publish the reviewed setup. Authorized users can then use the focused pack entry. ## Customize without losing the thread Adjust supported fields, labels, stage names and task-section presentation. Keep stable identities and review history as the configuration evolves. Deactivation retains existing work and history. Hidden sections are a presentation choice, not a security boundary. Paid capabilities still need their own server-granted access. ## About custom job billing **Planned capability** A Job Billing Work Pack is in design for approved-job timesheets, customer/job/role/employee rates and accounting review. It is not currently available to activate. Existing time tracking and dated per-person rate cards remain separate features. - Time and existing billing foundations → time --- # Docs & connected knowledge Make useful context easy to return to. Use Docs for decisions, delivery notes, guides and reusable context. Keep references alongside the projects and tasks that depend on them. ## Create in the right place Open a Work Area or folder and choose New doc. Its current location is used as the starting context. Give the document a clear title, structure the content and link relevant work. Use the existing document editor for authored content. Tasks can reference documents so people can return to the source without duplicating the explanation. ## Write for the next reader Start with the purpose and the decision or action the reader needs. Link the evidence, keep ownership clear and record significant changes. Useful titles and structure make search more effective. Access follows the document and its container. A link or mention does not open private knowledge to another person. ## Connect to external material Add supported file, folder or tool references when the source belongs elsewhere. A saved URL is a reference; it does not by itself authenticate an integration or synchronize its contents. --- # Time & billing Connect recorded effort to a reviewed invoice. Vision’s core time tracking keeps work, recorded effort and invoice evidence together. Use timers or manual entries, review the actual work, then create an invoice using the configured rates. ## Record time against the work Working schedules and leave describe availability for capacity planning. They do not replace actual time entries or automatically calculate payroll. 1. **Choose the task:** Open accessible work and confirm that your logging policy permits it. 2. **Track or enter the time:** Use the timer for live work, or add a manual duration or recorded interval. Include a useful note and the appropriate billable setting. 3. **Review My Time:** Inspect the period, work references and recorded entries. Correct eligible entries before invoicing. ## Control which jobs can be logged Owners and Admins can configure Administration → Time tracking with a default policy and per-person exceptions. Approved jobs only requires an explicit task or project approval. Project approval covers current tasks without giving access to private work. The policy applies to timers and manual entries. Revoking logging access retains recorded time; it does not erase the history. ## Apply the right dated rate An Owner or Admin defines per-person rate cards with an effective date, currency and optional task or project scope. Vision first looks for the person’s task-specific rate, then the recorded billing project, then the person default and the existing USD invoice fallback. The entry’s work date determines the applicable rate. Supported currencies include USD, EUR, GBP, CAD, AUD, NZD, CHF and SGD. Each invoice uses one currency, with no automatic conversion. Admins set tax percentages; a region label does not calculate tax law or payroll. Changing rates affects eligible uninvoiced work. Saved invoices keep their captured amounts. ## From completed entries to an invoice Invoice history lets you download the saved invoice again. A never-submitted invoice can be voided to release its entries for correction. Downloading does not send an invoice or collect payment. 1. **Choose the period:** Open My Time → Create invoice for a period of up to 32 days. 2. **Review eligible entries:** Select completed, billable, uninvoiced work. Running or paused timers are excluded; a project is not required. 3. **Confirm the details:** Review sender, customer, dates, references, hours, rates and totals. 4. **Create and download:** Create the invoice PDF. Vision reserves the source entries against duplicate billing and saves an immutable invoice snapshot. ## Use the optional accounting handoff Where a scoped Stark connection is configured for the person and Frame, explicitly submit the reviewed invoice for accounting review and refresh its status in Vision. The current Stark integration accepts USD. Other supported currencies remain available for PDF download. Submission is not accounting approval or payment. Keep destination, amount and customer details under review before any external handoff. ## Custom customer and job rates **Planned capability** The Job Billing Work Pack is in design for a broader customer/job/role/employee rate hierarchy and accounting review. That proposal is separate from the available dated per-person task/project rate cards described here. - Work Packs → packs - Bandwidth & capacity → bandwidth --- # Slack, GitHub & integrations Connect the conversation to the delivery record. Vision connects work to the tools that own the conversation, code and supporting material. Supported integrations have specific scopes; a selected platform badge does not promise a live integration. ## Connect a Slack channel An authorized owner can use Connect channel in a Work Area or the project’s connection settings to choose a verified Slack channel. Work Areas and projects can keep independent connections. Saving the channel does not enable every notification. Choose the event types and explicitly enable updates. Existing Slack intake and interactive actions follow the connected identity and work permissions. ## Link GitHub delivery evidence Connect relevant repositories, work and pull requests. Vision can present linked review/check state and delivery context while GitHub remains the source for code, reviews and detailed CI/CD evidence. Do not treat a linked pull request as approval to merge or deploy. Existing repository controls and Vision’s reviewed actions remain in force. ## Be precise about a connection A tool reference, saved storage link, authenticated connection and active workflow are different things. Verify the connection and supported actions before relying on an integration. Teams support is not identical to every Slack interaction. MCP access depends on the configured server, tools, grants and review policy. - Engineering & connected delivery → engineering --- # AI & automation Use intelligence where it helps. Keep control of the work. Vision’s core views and deterministic workflows work without model tokens. Optional XOS assistance adds configured Claude or OpenAI reasoning within administrator controls. ## Start with the core engine Common Start here answers, engagement deadlines, acceptance checks, views and reporting are based on recorded data and rules. They do not need AI to decide whether a check-in is overdue or a reviewer has accepted a handover. ## Configure assistance deliberately XOS requires the relevant paid add-on grant, a connected provider and administrator policy. Admins control permitted models, budgets and the kill switch. Fovelets are Vision’s specialist roles. For deeper Start here questions, automatic fallback can use a configured provider within those allowances. Missing evidence or setup is explained; no answer should fabricate missing records. ## Separate an answer from an action Source access, action permissions, approvals and revision checks are enforced by the server. A model response cannot grant itself access or bypass a budget. Start here answers do not execute model-proposed changes. MCP connections expose only their configured, authorized capabilities. They do not mean every external system is automatically indexed or searched. --- # Fields & configuration Structure useful information without crowding the task. Use labels for quick grouping and fields for consistent details. Keep the most useful values close to the work and leave configuration with authorized administrators. ## Use Field Library 1. **Open Administration → Field Library:** Owners and Admins manage task field definitions. 2. **Choose the scope and type:** Define a field for the Frame, Work Area or project. Supported types include Text, Number, Date, Checkbox, Select and URL. 3. **Add a clear name:** Use a label people can understand and fill consistently. 4. **Use it on tasks:** Permitted task editors fill values in Fields below Activity. ## Keep existing values safe Definitions can be renamed, extended with select choices, archived or restored. Their type and location stay fixed after creation to preserve meaning. Archived fields retain recorded values. Engagement fields have their own existing editor, linked from Field Library. They are not yet one combined catalog with task fields. ## Understand the lock Only an authenticated Owner or Admin manages definitions. A locked action leads through administrator sign-in; a shared password does not elevate a member’s account. Existing task edit permissions govern values. --- # People, access & setup Set up a useful workspace before expanding it. A Frame is the boundary for your organization’s people, access, integrations and settings. Keep initial setup focused on a real team and a real workflow. ## Administrator starting checklist 1. **Confirm the Frame:** Make sure you are configuring the intended organization. 2. **Set up people and teams:** Use active accounts and appropriate roles. Confirm identities before assigning imported work. 3. **Create the Work Area:** Choose ownership, access, optional folders and the views the team needs. 4. **Try a complete workflow:** Create work, assign it, record progress, request a review and finish the handover as the relevant users. 5. **Expand deliberately:** Add fields, packs and integrations once the basic workflow is clear. ## Access follows the work Frame membership does not mean every person can see every private record. Work Area, folder and record rules still apply. Search, reports, agents and connected workflows preserve those boundaries. Adding a view, linking a record or mentioning a person does not grant additional access. Test important workflows using the actual member role. ## Optional capabilities XOS, On-call, CMDB Lite and ITSM Lite require the relevant server-owned paid grants. A pack, prompt or workspace setting cannot grant them. Availability also depends on your deployed release and configuration. Use the in-product Help center for detailed operational guidance. Contact your Nano X representative for account or onboarding questions. --- # Bring your work into Vision Review the destination. Preserve the source identity. Vision provides import workflows for supported work and engagement exports. A successful migration starts with a clear source, destination and ownership mapping. ## Import customer engagements 1. **Prepare a supported export:** Use the engagement import workflow for a CSV or JSON export. Current batches support up to 500 projects and a 5 MB file. 2. **Choose the destination:** Confirm the Frame and an accessible Work Area/folder before proceeding. 3. **Map the records:** Review source IDs, statuses, fields, lead identities and initial check-in settings. 4. **Inspect the preview:** Resolve invalid rows and duplicate source IDs. Preserve the original ownership when no active account matches. 5. **Import, then activate the rhythm:** Map active leads and review check-in deadlines before expecting engagement obligations to run. ## Keep imported history in perspective A source modification date is not proof of customer contact. Unmatched accounts should remain Needs setup rather than being assigned to a convenient default person. An import does not create external accounts, grant source-system access or establish continuous synchronization. Keep the original source available until the imported results are reviewed. ## Make the imported work useful Open an imported record, verify its fields and ownership, and run a real workflow with the team. Use the focused Work Area and Engagements dashboard to establish the ongoing operating rhythm.