> For the complete documentation index, see [llms.txt](https://docs.lleverage.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lleverage.ai/run-operations/overview/project-dashboard.md). # Project overview Use the project overview to understand the operational area, current work and capabilities available in a Lleverage project. A Project groups the context and capabilities for a related area of operational work. When you open one, start by asking what business work this Project is responsible for: order intake, supplier follow-up, planning, accounts payable, master data, support, or another operational area. The product surfaces underneath only make sense in that context. ![A Production Planning project overview showing the project brief, pinned operational navigation and walkthrough.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2Fgit-blob-770279bee24dec3888b4894c0ec1604d8c31df62%2Fproject-overview.png?alt=media) ## Generated and custom overviews When a Project uses a pinned Overview and you have not customised that page, Lleverage can build the Overview from the Project's current content. The generated page adapts as the Project grows instead of showing empty sections. A newer Project can start with the basics and the Agent composer. As capabilities and work appear, the Overview can add relevant Apps, Workflows, Skills, Tables, open Requests and recently opened items. Projects with at least 100 runs in the previous 30 days can also get a **How it is going** section with operational charts such as run volume, completion, busiest Workflows, timing and App or Table activity. Blocks only appear when there is underlying content to show. Operators get a lighter generated view centred on the Apps, Requests and outcomes relevant to day-to-day work. ![A generated Project Overview built from current project content, including the How it is going activity section.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2Fgit-blob-4812d84daef86a4ace8c7f86e3ddf5a05b11679c%2Fgenerated-project-overview.png?alt=media) Editing the Overview switches it to a custom dashboard so you can control its content and layout. Existing custom dashboards stay custom. Use **Clear** if you want to discard the custom dashboard and return to the generated Overview. ## What to establish first Before going deeper, answer a few questions: * What operational work is this Project intended to support? * What should I use the [Agent](/run-operations/agent.md) for? * Are there published [Workflow apps](/run-operations/workflow-apps.md) I should use for structured tasks? * Could background Workflows create [Requests](/run-operations/request-inbox.md) for me? * Which connected systems and reusable context belong to this area of work? * If I am a builder, where do I inspect execution in [Monitoring](/build-and-improve/monitoring.md)? If you know the task but not the surface, use [Finding your way around a Project](/run-operations/overview/navigation.md). ## Projects are operational boundaries A Project is useful because its components belong to the same operating context. An order-intake Project might contain an Agent, [Skills](/build-and-improve/intelligence/skills.md) for interpreting orders, [Connections](/administer-and-govern/control/connections.md) to email and ERP systems, [Workflows](/build-and-improve/automate.md) for repeatable steps, maintained reference data and Monitoring for the resulting executions. The implementation can change while the underlying operational responsibility remains recognisable. For the conceptual distinction between Projects and customer-facing Solutions, see [Projects and solutions](/understand-lleverage/readme/projects-and-solutions.md). ## Use the overview as a launch point From here, move to the surface that matches what you need to do: * [Agent](/run-operations/agent.md) for flexible case-by-case work; * [Workflow apps](/run-operations/workflow-apps.md) for structured published processes; * [Requests](/run-operations/request-inbox.md) when background work needs your input; * [Automate](/build-and-improve/automate.md) if you are building or changing repeatable execution; * [Intelligence](/build-and-improve/intelligence.md) if you are maintaining Skills, data, files, Knowledge or Memory; * [Monitoring](/build-and-improve/monitoring.md) if you need to inspect what actually ran; * [Control](/administer-and-govern/control.md) if you administer access, systems or runtime configuration. The exact navigation available depends on the Project and your access. ## Related pages * [Run operations](/run-operations/overview.md) — operator path for day-to-day work. * [What Lleverage is](/understand-lleverage/readme.md) — the higher-level model behind Projects and execution. * [Operational examples](/understand-lleverage/operational-examples.md) — examples of the process language Projects commonly organise around. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.lleverage.ai/run-operations/overview/project-dashboard.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.