Skip to main content

MongoDB Access Request Procedure

Applies to: Requesting temporary access to a MongoDB Atlas project Where it happens: Slack → Linear Who this is for: Any Legion Security team member who needs Read Only or Read-Write access to a MongoDB Atlas project

1. Submit the Request​

  1. In Slack, run /linear, select Create New Issue, and then select the MongoDB Access Request template.
  2. Select the Administration team, if it isn't already the default.
  3. Fill in the form fields:
    • Project — the specific Atlas project you need access to
    • Access Type — Read Only or Read-Write
    • Purpose — a short justification (what it's for, not just "need access")
    • Needed until — if access is temporary; this sets the issue's due date
  4. Submit.

That's the entire requester-side action — no follow-up ticket routing, no manual pinging, and no special posting ritual required. Plain /linear is all you need; how you'll hear back is handled automatically regardless of how the issue was created (see Section 3).

2. What Happens After You Submit​

  • The issue is created in the Administration team, tagged with the Access Request label. It is not filed under a separate project — the label is what drives routing.
  • A saved Linear view scoped to that label automatically pushes a notification into the private #access-requests Slack channel, visible only to the fulfilling admins.
  • No manual triage step happens on your end — the right people are notified the moment you submit.

3. Receiving Your Access​

  • An admin will add you to the matching JumpCloud group for the project and access type you requested.
  • Access is granted through your existing SSO / JumpCloud login.
  • You'll get a Slack DM automatically the moment the admin marks the issue Done — that's your signal access is live, no polling the issue or asking around. The message includes what you requested (project, access type, purpose) and a direct link back to the issue.
  • If the request is declined or canceled instead, you'll get a different DM saying so, with a link to the issue for details on why.
  • If you haven't heard either way and it's time-sensitive, comment directly on the Linear issue (the link is in your original confirmation) rather than opening a duplicate request.

4. Expiration & Renewal​

  • If you gave a Needed until date, expect your access to be revoked on or around that date — this is by design, not an error. Revocation for MongoDB access is currently a manual step taken by the fulfilling admin, not an automated one.
  • If you still need access beyond that date, submit a new request (or comment on the existing issue) before it expires. Don't wait until after expiration to ask for an extension — that creates a gap in access and a messier audit trail.
  • If your need was open-ended and you left Needed until blank, your access won't be auto-revoked — but it's still good practice to close the loop with the fulfilling admin once you no longer need it.

Quick Reference​

StepWho does it
Run /linear, fill in template, submitYou (requester)
Routing to #access-requests (admin channel)Automatic (Linear)
Add you to the matching JumpCloud groupFulfilling admin
Mark issue Done or Canceled → auto-DM to youAutomatic, triggered by admin's status change
Revoke access at expirationFulfilling admin (manual)
Request renewal before expiryYou (requester)