<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=468849) </details> <!--IssueSummary end--> MR: Pending <!-- The first line of this issue description must be one of the following: 1. `MR: Pending` 2. `MR: <MR link with trailing +>`, 3. If there are multiple MRs: ``` MRs: - <MR 1 link with trailing +>` - <MR 2 link with trailing +>` - ... ``` 4. `MR: No MR` ...and the first description line of the MR should be `Issue: <Issue link with trailing +>` For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/index.html#relationship-of-issues-to-mrs --> <!-- The following sections should be filled out as part of the refinement process before the issue is prioritized. For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#2-pre-iteration-planning-meeting --> ## Description Created as a followup to this [thread in a feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/468070#note_1961467847). Currently during workspace creation, when no cluster agents are available to a user for workspace creation, an error message is displayed indicating that the administrator should configure an agent for the project or group. This is not particularly helpful as an agent may not be available for a myriad of reasons: - An agent that is expected to be available is inadequately misconfigured - Users do not have Developer+ access to any of the intended agents - With the new authorization feature, a working agent that is intended to be used for workspaces is not mapped to any parent group of the workspace project. ### Possible solutions 1. Update the existing message with all of the possible causes. However, this can make the message verbose and is less maintainable as it will require the message to be constantly in sync with the cases listed in the user docs. 2. Update the error message to nudge the user to consult the troubleshooting section of the Workspace docs. This allows the docs to be the SSoT which is preferable as the docs are better suited to house more detailed explanations/resolution steps. ## Acceptance Criteria - [ ] Determine the best course of action for this error message and update the acceptance criteria/technical requirements/design requirements ## Technical Requirements TBD ## Design Requirements TBD ## Impact Assessment TBD ## User Story TBD <!-- Replace with other type, e.g. bug or maintenance, if appropriate --> <!-- Replace with other subtype if appropriate --> <!-- By default, all issues start in the unprioritized status. See https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#-remote-development-planning-process --> <!-- For simplicity and to avoid triage bot warnings about missing workflow labels, we will default to issues starting at the refinement phase -->