Service Management
From order to installation: AppCloud365 packages in the OpsCloud365 service catalogue
Two products, separate data, one flow: how a software order in the self-service portal travels through approval and fulfilment group to a package from AppCloud365, and where the line between the two tools runs.
We are regularly asked whether OpsCloud365 and AppCloud365 are “connected”. The honest answer has two parts. Technically: no. They are two separate applications with separate databases, and each runs without the other. Organisationally: yes, at one point that comes up in IT every single day. Somebody needs a piece of software on their device. This article follows the path from order to installation and shows where each tool does its part.
The flow in five steps
Step 1: The order in the portal
In the OpsCloud365 self-service portal, staff find the service catalogue. An item such as “Install software” has its own order form asking for the application and the device. Price, lead time and whether approval is needed are shown on the item before anyone orders. The order becomes a service request with a number, which the requester follows under “My tickets”.
Step 2: The approval
Every catalogue item has an approval rule: none, the requester’s line manager, an approver group or a named person. The approval is created automatically when the request is raised and appears for the people responsible under “My approvals”. Rejecting requires a comment. After approval the request moves to in progress and lands with the fulfilment group configured on the catalogue item.
Step 3: The package from AppCloud365
Now the tool changes. The fulfilment group, usually the client team, searches the application in the mirrored WinGet catalogue of AppCloud365, checks version and installer and builds the package: as a PSADT package, as .intunewin or as a verified original installer. For applications that are ordered often, the package usually exists already and this step disappears.
Step 4: The deployment
The package is published in Microsoft Intune or Configuration Manager and assigned to the requester’s device. On request we set up this hand-over so that packages built in AppCloud365 land directly in the distribution system. What happens on the device is controlled by the package itself: close processes, install, report the exit code.
Step 5: The request is fulfilled
Back in OpsCloud365, the fulfilment group sets the request to fulfilled. The requester sees the status in the portal, can rate the handling, and the installation is traceable as software on the device’s asset if it is recorded there. From then on it counts as consumption for licence compliance.
Where the line runs, and why
It would be possible to couple the two products technically: a request that automatically triggers a packaging job. So far we have deliberately not built that. At this point the fulfilment group makes decisions an automaton should not make: which version, which installer, whether the package already exists, whether the application belongs in this organisation at all. The hand-over is a task for people who have good tools for it.
What the two products share is an attitude: orders have an approval, packages have a hash, and both have a history. If you use both, you have a continuous flow from the question “Can I have 7-Zip, please?” to the answer “It is installed.” If you use only one, you lose nothing the other could not do on its own.
All images show the real application with fictitious demo data.