For AI agents and LLMs: a machine-readable index is available at llms.txt. A plain-Markdown version of any documentation page is available by appending .md to its URL.
Skip to main content

Omni Projects New

An Omni project is a SmartUI project type in which every capture source can co-exist. A single Omni project accepts website screenshots, native app screenshots, PDFs, Figma designs, Storybook components and directly uploaded images, side by side in the same project. Each capture run still produces its own build, and builds from different sources sit together in the same build list.

Standard project types work the other way around. A standard project is created for one source, and that choice is fixed: a Website project accepts website captures, a PDF project accepts PDFs, an App project accepts app screenshots. Sending a different source type to a standard project is rejected, and the run fails with a project type mismatch telling you the project already exists with a different platform type, and to either use a different project name or create a project of the platform type you are sending. Covering a release that spans web, mobile and documents therefore means creating and managing several projects side by side.

Omni vs Standard Projects​

Omni projectStandard project
Capture sources acceptedWebsite, App, Figma, Storybook, PDF, ImageOne source, fixed at creation
Sending another source typeAcceptedRejected with a project type mismatch error
Projects needed for a web + mobile + PDF releaseOneOne per source
Configuration screenOne tab per capture sourceInstructions for the project's own source
Baseline selectionPer git branchOne baseline for the project, except CLI projects, which are also per git branch
Build listOne chronological list across all sourcesGrouped into Baseline Build and Non Baseline Build

The practical difference is consolidation. A team shipping a feature across a web app, a mobile app and a generated PDF statement can run all three into one Omni project and read one build list, instead of aggregating status by hand from three projects.

What this means if you are migrating​

For an enterprise team weighing a move, the differences that actually change day to day work are these.

Fewer projects, and one place to look. A release that spans a web app, a mobile app and generated documents needs one Omni project rather than three. Approvers, tags and settings are configured once rather than kept in step across projects, and the release status is read from one build list.

Branch aware baselines. This is the change most likely to affect an existing pipeline, and how much it affects you depends on where you are coming from.

  • Coming from a CLI project, nothing changes. CLI projects already resolve baselines per git branch, and Omni behaves the same way.
  • Coming from a Website, App or PDF project, this is new. Those resolve against one baseline for the whole project, whereas Omni resolves per branch, so a feature branch compares against its own branch's baseline rather than against whatever the project's single baseline happens to be.

If your runs do not currently send branch information, add it before migrating, because Omni treats a build with no branch as being on the default branch.

A different baseline mental model in the dashboard. A standard project separates its build list into a Baseline Build and Non Baseline Build section, so the baseline is a specific build you can point at. An Omni project shows one chronological list, and the baseline is resolved per branch rather than being a single pinned build. Teams with a documented approval process that references "the baseline build" will want to revisit that wording.

Document annotation is materially better on Omni. In a standard PDF project a region applies only to the page you drew it on, so a 40 page document means 40 regions placed by hand. Omni adds page level propagation plus Element Based Anchoring, so one region can cover the whole document and follow the anchored content as the pages reflow. For teams testing statements, invoices or policy packs this is usually the single biggest reason to move.

Nothing changes for how you capture. The CLI commands, SDK hooks and APIs are the same. Omni changes which project accepts the artifact and how baselines are resolved, not how the screenshot is taken, so existing test code does not need rewriting.

Existing projects are unaffected. Projects created before Omni was enabled keep their original type and behaviour. Migration is not automatic, and there is no in place conversion of a standard project into an Omni one, so plan for new projects rather than a switch on existing ones.

Capture Sources​

Every source below can be used in the same Omni project. Each one keeps the workflow it already has, because Omni changes where the results land, not how you capture them.

Browser-based capture, through any of the supported routes:

  • CLI exec mode, to wrap an existing automation suite, for example npx smartui exec -- npx cypress run
  • CLI capture mode, to capture a list of static URLs with npx smartui capture urls.json
  • SDK hooks, calling smartui.snapshot() directly inside your test code
  • Web Scanner, for no-code crawling of a site

Where Each Source Is Set Up​

The project configuration screen carries one tab per capture source: Website, App, Figma, Storybook, PDF and Image. Each tab holds the integration instructions for that source, including the CLI, SDK and API routes where they apply, along with the project token to authenticate with.

In a standard project this screen shows the instructions for the single source the project was created for. In an Omni project all six tabs are available, so you can add a second or third source to a project that is already running without creating a new one.

Reading Results​

Results for every source land in the same place. The project's build list holds builds from all sources in one chronological list, and opening a build shows the screenshots captured in that run, whether they came from a browser, an app, a design file or a PDF.

Within a build, the All and New tabs filter by screenshot status rather than by source, and PDF pages are shown as variants of the document they came from.

How Artifacts Are Matched​

Mixing sources in one project only works if SmartUI never compares two things that should not be compared. Omni handles this by matching each artifact against a baseline of the same source, using a key appropriate to that source.

Visual sources​

Website, App, Figma, Storybook and Image artifacts are all raster images, and are matched on a composite key:

Screenshot Name + Browser + Resolution + Device Name + OS

Every part of the key must match for a comparison to run. This is what stops a Chrome capture being compared against a Firefox baseline, or a desktop capture against a mobile one.

PDF sources​

PDF artifacts are documents rather than raster screenshots, and are matched on their own key:

Screenshot Name + Document Name + Page Number + Resolution

PDFs are kept in a separate logical space from the visual sources, because document comparison and pixel comparison are different operations. A PDF is never compared against a website, app, Figma, Storybook or image artifact, and vice versa.

Same name, different sources​

Because matching is source-aware, a PDF named Report and a web page named Report can live in the same project without colliding. They stay two separate entries and neither overwrites the other.

Similarly, two artifacts that share a name but were captured at different resolutions, say a page captured at 390x844 and the same page at 1920x1080, are treated as separate entries rather than compared against one another.

Working with Regions in an Omni Project​

Annotations behave the same way in an Omni project as anywhere else, and the region types and scope controls are unchanged. What differs is the axis a region propagates along, which follows the source of the screenshot you drew it on:

  • On a PDF artifact, a region can be applied to every page of that PDF, and Element Based Anchoring places it on the anchored content page by page. Both controls are specific to Omni; in a standard PDF project a region stays on the page it was drawn on.
  • On a website or app artifact, a region can be applied to every browser and viewport variant of that screenshot.

Availability and Access​

Omni projects are released behind a feature flag and are rolled out progressively.

Enabled per organisation

Omni is switched on for an organisation as a whole, not per user or per project. Once it is enabled, every project you create is an Omni project regardless of which creation flow you use, and it accepts all six capture sources from the start.

  • Existing projects are not converted. Projects created before Omni was enabled keep their original type and continue to behave exactly as they did, accepting the single source they were created for. There is no in place conversion, so plan for new projects rather than a switch on existing ones.
  • You can tell the two apart from the dashboard URL. An Omni project opens under /test/omni/, while a standard project opens under its own platform, for example /test/pdf/.
  • If you expect Omni and do not see it, your organisation may not be enabled yet.

To have Omni enabled for your organisation, contact support at support@testmuai.com or use 24/7 Chat Support.

Best Practices​

  • Group by release, not by source. The value of an Omni project comes from one project covering a whole release. Splitting by source recreates the silos Omni exists to remove.
  • Keep screenshot names stable across sources. Names are part of every matching key, so a rename is read as a new artifact rather than a change to an existing one.
  • Keep git branch information accurate on every run. Omni resolves baselines per branch, as CLI projects do, so a missing or wrong branch sends a build to compare against the wrong baseline.
  • Keep viewports consistent between runs. A changed resolution produces a new entry rather than a comparison.

Additional Resources​

Last updated on

Terminal First Testing With Kane CLI

Natural language browser & mobile app tests right from terminal.

×
Schedule Your Personal Demo
Kane CLI terminal

Help and Support

Related Articles