Creating a Project

A project is a scoped view of your workspace's data: the object types and event types you want in play, the events that mark a process finished, and everything built on top — the map, variants, filters and conversations.

What is a project?

A project is where analysis happens. The workspace holds the data; the project decides which of it is in scope and gives you somewhere to work.

• Choose the data — which object types and event types to include
• Say where the process ends — so completion and cycle time mean something
• Work in it — map, variants, filters, metrics, board, copilot, all scoped to that choice
• Share it — invite people to the project without giving them the whole workspace

Workspace, dataset, project

Workspace — the container. Holds every dataset, shared by everyone you invite.

Dataset — what an upload produced: objects, events and the relations between them. A workspace can hold several.

Project — an analysis view over that data. Several projects can read the same datasets with different scopes.

Creating a project

Step 1: Name it

From your workspace, open Projects and create a new one. You get two fields:

• Project Name — required. Name it for what you are analysing: "Order to Cash", "Blocked Orders", "Invoice Clearing".
• Description — optional. What the project is for, and anything a colleague opening it cold would need to know.

Click Create project. Both fields can be changed later in project settings.

Step 2: Select your data scope

The setup wizard opens on Select Your Data Scope. You see the workspace's object types with their related event types nested beneath, and a running count in the heading: how many object types and event types are selected out of how many exist.

Tick the object types this analysis needs, and within each, the event types. For a first project, taking everything is usually right — you cannot know what is noise until you have seen the whole process.

Where a project spans more than one object type, one becomes the default lens: the object the map is centred on. Flow Myna picks the most connected type, and you can switch the lens at any time on the map, or overlay events from related objects without changing it. See Process Map.

Step 3: Define process end points

The second step is Define Process End Points: which event types mark a process as finished. This is what makes "completed", "still in flight" and cycle time mean anything, so it is worth a minute of thought.

Flow Myna proposes terminal events from your data and shows the evidence behind each proposal:

• Last Event — how often this event is the final one for an object
• Position — how late in the flow it typically sits
• Confidence — how sure the suggestion is, with an AI Selected badge on the ones already ticked

A Completion coverage panel shows what proportion of your objects would count as complete under the current selection. If that number is far from what you expect, the selection is probably wrong.

You have the final say: tick and untick freely. An event that is the last one for nearly every object and sits at the very end of the flow — Clear Invoice, for invoices — is a clear end point; one that is rarely last and sits mid-flow almost certainly is not.

Finish the wizard and the project opens.

The project home

The project's home page is the summary you land on:

• Objects and Events, with how many types of each
• Avg [object] duration — the mean cycle time: a completed object is timed from its first activity to its finish, an open one to the latest activity in the data. The population it was computed over is stated underneath
• [Objects] completed — how many reached a process end point. If you have not defined end points yet, this tile says so and links you back to the wizard.
• Recent Conversations, with a link to the full list
• Quick Actions, and an Ask Your Process button that opens the copilot

Data Scope

Scope is not a one-time decision made in the wizard. Data Scope is a page in the project, and you can change it whenever the analysis needs something different.

It opens with four counts — object types included out of available, event types included out of available, how many distinct processes the workspace holds, and how many terminal events are set — then three sections:

Object Types — every object type in the workspace, grouped by the process it belongs to, each marked Included or not. Grouping matters once a workspace holds more than one process: it keeps an order-to-cash project from being buried in another process's object types.

Event Types — the same, per event type, each card naming the object type it hangs off.

Terminal Events — which events mark the end of the process, per object type. The same choice you made in the wizard, editable here.

Changes take effect across the project: the map, variants, filters and the copilot all read the same scope.

When to change it

• The map is too busy — drop the detail event types
• You want a specific phase — narrow the events, or use the map's Crop control
• An object type you excluded turns out to matter — add it back
• Completion looks wrong — revisit the terminal events

Project settings

General Settings holds the project name and description, and shows the project ID, the workspace it belongs to, and when it was created and last updated. A Danger Zone at the bottom deletes the project and everything in it.

Access is managed separately, on the Collaborators page.

Sharing a project

Projects are shared by inviting people to them; there is no separate visibility switch. Collaborators shows who has access, their role, when they were last active and when they joined, plus any pending invitations.

Project roles

• Admin — full control of the project, including inviting and removing people
• Member — can explore the project, apply filters, save filters and use the copilot

A workspace Guest sees only the projects they were added to, which is what makes projects the right unit to share with consultants and stakeholders. See Collaboration.

Any filtered view can be shared as a URL with anyone who has access to the project — the filters travel in the link.

Working with several projects

A new project, or a filter?

Worth a new project

• A different object focus — customer-centric rather than order-centric
• A different phase of a long process, where a different scope genuinely helps
• A different audience who should not see the rest of the data

Use a filter instead

• Value ranges, statuses, regions, risk levels
• Time windows
• Any question you might want to ask again next week — save it as a filter

Filters are cheap, shareable and stack; projects are a scope decision. Reach for a filter first.

Keeping projects legible

• Name for the focus: "Order to Cash — Blocks"
• Keep descriptions current; they are what a colleague reads before opening
• Delete experiments rather than letting them accumulate

Troubleshooting

The project is empty

Check that at least one object type and one event type are included in Data Scope, and that the dataset finished transforming. A project scoped to object types with no events will draw nothing.

The map is unreadable

Too many event types is the usual cause. Drop the rare ones in Data Scope, or leave the scope alone and use the map's Common flows slider, which drops whole objects rather than parts of them so the numbers stay true.

Completion looks wrong

Almost always the terminal events. Open Data Scope, look at the Terminal Events section, and check the completion coverage against what you know to be true.

Next steps

See the process

• Process Map — the flow your data describes
• Process Variants — the distinct paths through it

Let the analysis come to you

• Co-Pilot — ask questions in plain language

Narrow it down

• Filters & Exploration — build and compare cohorts