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.

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.

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 for?

• Are there published Workflow apps I should use for structured tasks?

• Could background Workflows create Requests 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?

If you know the task but not the surface, use Finding your way around a Project.

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 for interpreting orders, Connections to email and ERP systems, Workflows 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.

Use the overview as a launch point

From here, move to the surface that matches what you need to do:

• Agent for flexible case-by-case work;

• Workflow apps for structured published processes;

• Requests when background work needs your input;

• Automate if you are building or changing repeatable execution;

• Intelligence if you are maintaining Skills, data, files, Knowledge or Memory;

• Monitoring if you need to inspect what actually ran;

• Control if you administer access, systems or runtime configuration.

The exact navigation available depends on the Project and your access.

Related pages

• Run operations — operator path for day-to-day work.

• What Lleverage is — the higher-level model behind Projects and execution.

• Operational examples — examples of the process language Projects commonly organise around.