How a tool fits ResorsIT
Every tool in this catalogue carries a ResorsIT usage value: a single label that says how the tool can be brought into the ResorsIT platform. It answers “if we adopted this, how would it actually be integrated?”
The value is chosen by precedence. A tool that could be integrated more than one way is labelled by its primary, richest integration – for example a web app that also ships as an installable package is still a Web App, not a Deployment Payload.
The usage modes
| Usage | Meaning |
|---|---|
| Native App | First-party app that runs only inside ResorsIT |
| Web App with SSO | Web app integrated through ResorsIT single sign-on |
| Web App without SSO | Web app surfaced as a Hub link; separate login |
| Deployment Payload | Installed on a desktop or server |
| Device Class | Hardware, firmware, or an operating system |
| Library | Code library used inside customer-developed code |
Tools that fit none of these
A small number of tools do not fit any single mode cleanly – a data feed, a standard, or something used only indirectly. These are marked Not integrated. The label is a starting point for judgement, not a guarantee that ResorsIT ships an integration today.
Each tool page shows its usage under ResorsIT usage, linked to the matching page here.
Usage is not the same as access
The usage label answers how the platform adopts a tool. It does not say how a person signs in to it – and single sign-on is only one of several answers. A tool with no SSO is not just a bookmark: it can be gated at the proxy, checked against the directory, provisioned automatically, or reached with a governed credential. See Access & Identity for the full set of access methods.
