Permit clerks see their Horizon desktop as a tile next to web apps in the Access/Hub catalog. What does Workspace ONE Access do in that design?

Permit clerks see their Horizon desktop as a tile next to web apps in the Access/Hub catalog because Workspace ONE Access catalogs entitled Horizon desktops and apps after Access authenticates the user, while Horizon Connection Server still brokers the actual session. Access is the lobby directory that can list the Horizon floor; Connection Server remains the elevator that takes the clerk there. One Hub tile does not mean Access became the PCoIP or Blast broker. The distractor that Access replaces Connection Server and brokers PCoIP itself fails by concept: Access integrates with Horizon for catalog and authentication hand-off, but brokering, protocol negotiation, and pool selection stay with Horizon infrastructure. The claim that Access installs Horizon Agent on each clerk PC fails because Horizon Agent belongs on the virtual desktop or RDSH host, not as a catalog side effect of Access, and Access does not turn a physical PC into a pool agent. Converting the Horizon pool into a Workspace ONE UEM internal application package fails because UEM internal apps are mobile/desktop packages managed for enrolled endpoints; a Horizon pool entitlement is not repackaged as a UEM internal app merely because Access lists it. Exam caveat: end-to-end success still needs Horizon entitlements, Connection Server health, and often Unified Access Gateway for external users; Access catalog presence alone does not prove the desktop will start. Operational check: authenticate in Intelligent Hub, select the Horizon desktop tile published through Access, confirm Connection Server brokers the session and Horizon Client or the appropriate client path connects, and verify Access did not itself negotiate the display protocol.