Self-Service Automation Catalog Portal Design Prompt
Design a self-service catalog that lets engineers safely run curated automation jobs on demand, with parameter validation, RBAC, approvals for risky actions, and an audit trail, without handing out raw runbook access.
- Target user
- Platform engineers building internal self-service automation portals
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a platform engineer building a self-service portal so product teams can run common operational automations themselves, after a well-meaning engineer once ran a raw teardown script against the wrong environment because there were no guardrails around it. I will provide: - The automations to expose, their parameters, and their blast radius - The identity/RBAC system and how teams and roles are modeled - The execution backend (Rundeck, GitHub Actions, Argo Workflows, an internal runner) - Which actions are safe to self-serve vs. which need approval Your job: 1. **Catalog model** — define an automation as a catalog entry: typed parameters with validation and allowed values, a description of effects, and its blast-radius classification. 2. **Parameter safety** — constrain inputs so a user cannot target the wrong environment or an out-of-scope resource: enumerated choices, scoped selectors, and server-side validation, not free-text. 3. **Authorization** — map who can see and run each entry to [RBAC], so visibility and execution rights follow role and team ownership, not a shared credential. 4. **Approval gates** — require an approval step for high-blast-radius entries, with who can approve, a timeout, and what happens on expiry. 5. **Execution isolation** — run each job with a scoped, per-execution credential rather than the portal's own broad identity, so a catalog entry cannot exceed its declared scope. 6. **Audit trail** — record who ran what, with which parameters, when, and the outcome, as an immutable record tied to the requester's identity. Output as: a catalog-entry schema, the RBAC and approval matrix, the execution/credential-scoping model, and an audit-event schema, plus one worked example from a safe entry and one from an approval-gated entry. Validate the parameter constraints and RBAC on a staging portal with a non-admin test user before exposing any destructive entry; confirm a user cannot craft parameters that escape the entry's declared scope.
Run this prompt with AI
Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.
Why this prompt works
A self-service portal is leverage in both directions: it lets teams run operations without a platform bottleneck, and it lets them run operations without a platform bottleneck. The motivating failure — a teardown against the wrong environment — is what happens when convenience arrives before guardrails. The prompt reframes each automation as a catalog entry with typed, validated parameters and a declared blast radius, which turns “run this script” into “invoke this constrained action.” That single shift is what makes self-service safe to offer at all, because it moves the safety boundary from the user’s discipline to the entry’s definition.
The two constraints the prompt is strictest about are parameter safety and credential scoping, because they are the two ways self-service actually goes wrong. Free-text targeting is how a typo becomes a production incident, so the prompt demands enumerated choices and scoped selectors validated server-side, where the user cannot bypass them. And a portal that runs everything as its own broad identity gives every catalog entry the portal’s full power regardless of what the entry claims to do — so per-execution scoped credentials are what make the declared blast radius real rather than decorative.
The remaining pieces close the governance loop: RBAC ties visibility and execution to role and ownership instead of a shared credential, approval gates put a real second party in front of irreversible actions, and an immutable audit trail tied to the requester’s identity means every run is attributable. The model can produce the schemas and matrices quickly, but you test the constraints with a non-admin user on staging before exposing anything destructive, because the whole point of the portal is to hand execution to people who are not you.
Related prompts
-
ChatOps RBAC Command Authorization Design Prompt
Design role-based authorization for a ChatOps bot so every chat-triggered command checks who issued it, in which channel, against an explicit policy — before it touches infrastructure.
-
Human-in-the-Loop Approval Authority Design Prompt
Design the decision-authority model for human-in-the-loop automation — who may approve which action tier, when two-person review or quorum is required, how approvers get the context to decide well, and how break-glass and timeouts work without weakening the controls.
-
Read-Only-by-Default Automation Promotion Prompt
Design a maturity model that ships every new automation in read-only/observe-only mode first, then promotes it through suggest, gated-act, and finally auto-act tiers only after it earns trust with evidence — so nothing changes production state on day one.
-
Approval-Gated Destructive Automation Policy Engine Prompt
Design a policy engine (OPA/Rego or equivalent) that intercepts automated actions at runtime and enforces approval, blast-radius, and time-window rules before destructive operations run.
More Automation prompts & error guides
Browse every Automation prompt and troubleshooting guide in one place.
Reading prompts? Get all 500 in one free PDF
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.