The Infra Dashboard, end‑to‑end.

§1About this manual

Written to be scanned, not read cover-to-cover. Every section is tagged with the roles it applies to — read yours, skim the rest.

Three roles keep the portal moving: User, Project Coordinator, and Program Manager. Roles are additive — a Project Coordinator can do everything a User can, a Program Manager can do everything a Project Coordinator can. If you carry more than one hat, read the union of the sections that apply.

In our organization, Project Coordinator and Delivery Lead are the same role — the terms are used interchangeably. Everything the manual calls out for the Project Coordinator applies whether your title is PC, Delivery Lead, or both.

Everything below is grounded in the current release. Wherever a workflow has a hidden constraint — a policy, a lock, a window — the manual calls it out where it matters, not in a footnote.

§2What Infra Dashboard is

One portal, every AWS account, permission-scoped views, and an audit trail behind every action.

The Infra Dashboard consolidates operational access to every AWS account we run under a single login. Instead of switching consoles, hunting for the right role, or asking someone to run a command, the portal shows every resource in scope for the person signed in, and lets them act on it directly — subject to policy.

The underlying model is deliberate:

• Identity is the source of truth. Your role and the accounts you're mapped to decide what you see. Change either, and the portal reflects it within seconds.
• Every write goes through a request. A Start, Stop, Restart, Modify — even executed instantly — leaves a request row you can search later.
• Locks prevent duplication. Once you've opened a request on a resource, no one else can open a second one until yours settles.
• Policy is a first-class configuration. Whether a Start must specify a stop time, whether a resource type is even visible, is set once at the role level.

§3Roles at a glance

Three working roles, cumulative in scope. Everyone can do what the roles beneath them can — the additional column is what changes.

§4Getting in

One login for web and mobile, biometric on the phone, OTP as a backup channel when a password isn't set.

4.1Web portal

Go to infra.camview.io. Sign in with the email your admin registered you under. If you've been onboarded but haven't set a password, use the OTP option — a 6-digit code arrives in your inbox from otp@camview.io within a minute.

4.2Forgot password

1. On the login screen, tap Forgot password.
2. Enter the email or employee ID your admin set up.
3. An OTP arrives from otp@camview.io. Enter it, then pick a new password.
4. The old sessions on other devices are unaffected — sign out from Settings if you want them cleared.

4.3Mobile app

The Android APK is distributed by your admin. First launch asks for your credentials. Once you're in, turn on Biometric login in Profile → Preferences. From then on, opening the app after a background window prompts your fingerprint instead of your password. See §12 for details.

§5Everyone — first steps

The five minutes after your first sign-in decide how comfortable you'll be for the next month. Spend them here.

5.1Read the sidebar

The left sidebar (or the drawer behind the ☰ button on phones) is the map. Groups are labelled: Operate, Workflow, Administration. Items you don't have permission to reach never appear — the sidebar is authoritative for what's available to you.

5.2Set your Preferences

• Theme — light, dark, or follow system.
• Auto-refresh — how often the dashboard re-fetches the active account (5, 10, 15, 30, or 60 seconds).
• Auto-lock — how long the app stays signed in when idle. Default 5 minutes.
• Biometric — mobile only; requires an enrolled fingerprint or face.

5.3Understand the Overview

The Overview page (§3 counts, § accounts, § resources) is the sanity check every morning. If a KPI looks wrong, the account tabs at the top narrow the view to one account at a time. The rotating refresh icon in the top bar is manual — it also restarts the auto-refresh timer from now.

§6For Users

You raise requests. The system decides whether it can execute them right now, or whether they need a Coordinator's nod first. Either way, the history is yours to track.

6.1Viewing your resources

Open EC2, RDS, or S3 from the sidebar. Everything you see is inside your access scope — assigned account, resource, or tag. If a colleague has different resources visible, that's their scope, not a bug.

Filter chips at the top narrow by account and by state. The search box matches instance ID, name, and tag values.

6.2Submitting a Start / Stop

1. Find the resource in the table. If someone else already has an active request on it, you'll see a REQUEST PENDING chip in place of the action buttons — that's the resource lock. Wait for their request to settle.
2. Tap Start or Stop. A confirm dialog appears.
3. Confirm. The dialog closes immediately and a toast reports the outcome. The state on the row updates within one auto-refresh cycle.
4. If your role requires a stop time (see §6.3), the runtime dialog opens first. Pick a stop time or select Run indefinitely.

6.3Mandatory stop times

Some roles have a shutdown policy of Mandatory. That means every Start request must declare either a stop time or Run Indefinitely — silence-is-consent is not accepted. The runtime dialog is pre-filled with a reasonable default; adjust as needed.

Under Optional, the runtime section is offered but not required. Under Disabled, the approver picks the stop time at approval — you don't need to worry about it.

6.4What to expect after submit

• Executed — action ran; state will change within a refresh cycle.
• Pending approval — a Coordinator has been notified. You'll get a portal notification when they act.
• Rejected — the reason is in the row. You can raise a new request with the correction.
• Failed — the dispatch reached AWS but something errored. Contact your Coordinator with the request ID.

6.5Reading your history

Sidebar → Request History. The list is paginated on the server and covers the full retention window — filter by date, account, resource, action, or status. The CSV export walks every matching row (not just the current page) so it's honest for reporting.

§7For Project Coordinators

You keep exams running, changes scheduled, the right people informed, and every request through the loop — from the moment a User raises it to the moment it settles.

7.1Server Running Hours

A window during which specific servers are usable — inverse of maintenance. Outside the window, non-admin users can't Start the resource; inside, they can. Admins keep their override.

1. Sidebar → Server Running Hours → Schedule.
2. Pick a scope: single resource, all resources tagged with a value, or an entire account.
3. Enter Start and End date/time. IST is the default; the recipient sees IST regardless of their locale.
4. Optional: enter Uptime and Downtime — a scale-up/scale-down bracket inside the window. Leave blank to skip.
5. Enter an Exam name, Environment, and an availability message that appears to users who try to start outside the window.
6. Toggle Send email notification if you want the recipients to know. Pick recipients from Users, Roles, Accounts, Groups, or type custom emails.

7.2Maintenance windows

Blocks Start requests during the window on the scoped resources. Same three-way scope (resource, tag, account). Same recipient picker for the notification. Use for planned downtime; use Running Hours for the inverse.

7.3Email Recipient Groups

A named list of portal users and external email addresses. Create once, reuse everywhere. Sidebar → Email Groups.

• Create the group, name it after the audience (e.g. Ops on-call, ITSM leads).
• Add members — pick portal users from the dropdown, or paste external addresses.
• Import CSV in label,email or email format for bulk seeding.
• Export CSV for your records.

Once a group exists, it appears in the composer's Groups tab across Running Hours, Maintenance, Exam Planner, and any future notification surface.

7.4Sending notifications

Every scheduling surface exposes the same composer. Pick a subject, edit the body, add recipients (mix Users / Roles / Accounts / Groups / custom emails), send. The composer attaches a professional infrastructure details table to the email — account, environment, tag key/value, resource type, project code, exam window, upscale/downscale times — so recipients see the full context without follow-up.

Every send is logged, linked to the schedule row it was fired from, and shown as a Notification sent chip next to the schedule so you can see at a glance whether a re-send is needed.

7.5Approving requests

Sidebar → Requests. Pending rows sit at the top with the requester, the resource, the action, and the runtime they proposed. Tap Approve or Reject.

• On Approve, you can accept the requester's stop time, override it with your own, or clear it entirely by selecting Run indefinitely. The chosen runtime is what auto-stop enforces.
• On Reject, add a short reason — it shows up in the requester's history and their notification.
• The resource lock releases automatically as soon as the dispatch is sent. The REQUEST PENDING chip drops off the requester's view within one refresh cycle.

7.6Autopilot rules

A rule is a policy: "when a pending Start request older than N minutes matches this scope, execute it and stamp an auto-stop for M minutes later." Sidebar → Admin → Autopilot.

• Scope by account, resource type, and tag.
• Set the pending delay before autopilot picks it up, the active window (24×7 or specific hours), and the auto-shutdown minutes.
• Optionally set a default instance type — Autopilot will resize the instance on Start if it differs.
• Every autopilot dispatch writes a row to Execution History with the reason, outcome, and shutdown time, and fires an email to the requester + your configured recipients.

7.7RBAC — Roles and Templates

Sidebar → Admin → Roles. A role is a container. Attach it to users, groups, or departments. Every permission a person carries flows through a role — nothing is hard-coded to the person.

Inside a role, four permission surfaces stack:

• Feature — turn EC2 / RDS / S3 / Exam Planner on or off for the role.
• Account — restrict to specific AWS accounts.
• Resource — pick individual instances, buckets, or databases.
• Tag — grant access to everything with a matching tag.

Any of the four grants access. The most-permissive rule wins on union. The portal evaluates in the same order every time: Feature → Account → Resource → Tag.

7.8User onboarding

Self-signup lands in the Onboarding queue. Review the person, assign a role, and approve — they receive credentials by email. Reject sends a rejection email with your reason. Hold pauses the queue entry without notifying.

7.9Audit log

Every write in the portal — request, approval, admin action, notification — leaves an audit row. Sidebar → Audit Log. Filter by user, action, or status. Combined with Request History, this is the paper trail for any incident review or compliance conversation.

§8For Program Managers

You plan the batch that a User raises one at a time. Advanced Requests and Exam Planner are the two surfaces that pay for themselves inside a month.

8.1Advanced Requests

Schedule a single request or a batch to run at a future time, with an automatic stop.

1. Sidebar → Advanced Requests → New.
2. Pick the AWS Account, then the Resource Type (EC2, RDS, S3).
3. Pick a selection mode:
   • Specific resources — the picker fetches the live inventory for the account, lets you search by ID / name / tag key / tag value, and multi-select with Select all or Clear. Locked resources show a REQUEST PENDING chip and stay unselectable.
   • Batch by tag — one criterion resolves at execution time against live inventory.
   • Batch by account — everything of the type in the account, resolved at execution time.
4. Pick the action, execute time, and optional end time. If your role's shutdown policy is Mandatory, provide an end time or explicitly select Run Indefinitely.
5. Submit. Each selected resource becomes its own row, with its own audit trail. Locked resources are skipped and reported in the response summary.

8.2Exam Planner

Scoped to Account-1 (the distribution account). Plans an exam against a Distribution ID (D1–D25), with project code, client name, and window. Detects conflicts against existing exams and refuses to overlap unless you have Override permission.

On create, update, or cancel, toggle Send lifecycle email to notify the mailing list attached to the distribution. Manual composer sends are still available for hand-authored announcements.

8.3Reports and CSV exports

Sidebar → Request History. The list itself is the report. Filter by date range, user, account, resource type, and status. The CSV export walks the full filtered set, not just the visible page — the export is honest for handover to audit or the client PMO.

§9Cross-role workflow map

Common flows and who owns which step. Use this as a quick "who does what" reference during a live incident.

§10Mobile Android app

Everything a User does on the web, in your pocket — plus native biometric unlock and a background auto-refresh that keeps the dashboard current between glances.

10.1First run

1. Install the APK from your admin. Open the app.
2. Sign in with your work email and password (or OTP).
3. Once you land on the dashboard, go to Profile → Preferences.
4. Turn on Biometric login. Confirm with your fingerprint/face.
5. Set Background refresh to 10 s (default) or your preferred cadence.

10.2Everyday use

• Cold-start the app: fingerprint prompt appears, no password re-entry needed.
• Backgrounded for the auto-lock window: fingerprint again on return.
• Rotating refresh icon in the top bar spins while the auto-refresh is fetching. Tap it for an immediate refresh.
• The mobile app respects the same RBAC as the web — you'll only see resources you're assigned.

§11Reference

Request statuses, notification identities, and a short glossary for the terms that keep coming up.

11.1Request statuses

pending

Awaiting approval by a Coordinator. Lock is held.

under_review

A Lead has opened the request; not yet decided.

approved

Decision made. Dispatch is imminent.

scheduled

Advanced Request — approved and waiting for its execute time.

executing

Lambda is running.

executed

Dispatched to AWS. State on the resource updates next refresh.

executed_by_autopilot

Same as executed, but Autopilot ran the request without human approval.

completed

Terminal success.

rejected

Lead declined. Reason is on the row.

cancelled

Withdrawn before execution. Lock is released.

failed

Dispatched but AWS returned an error. Contact your Coordinator.

expired

Approved but the execute window elapsed before dispatch.

11.2Notification identities

otp@camview.io

OTPs — signup verification, password reset, login codes. Add to your inbox safelist.

no-reply@camview.io

Every other portal notification: request outcomes, approvals, maintenance, running hours, exam planner, advanced requests, autopilot. Add to your inbox safelist and Do-Not-Reply.

11.3Glossary

Resource lock

Held while a request is in a non-terminal state. Prevents duplicate requests on the same resource by anyone.

Shutdown policy

Role-level toggle: Disabled / Optional / Mandatory. Decides whether a Start request must specify a stop time.

Runtime mode

The declared shutdown intent on a Start request: SCHEDULED (stop at time X) or INFINITE (no auto-stop).

Direct execution

An action that dispatches immediately without approval. Governed by role — Coordinators have it broadly; Users have it for non-prod.

Autopilot rule

A rule that automatically approves and executes pending requests matching a scope, inside an active window, with an auto-stop.

Scope

The set of resources visible and actionable to a given identity. Derived from the roles attached and the accounts / resources / tags they grant.

§12Getting help

The right first contact by symptom. Almost every operational question is a five-minute conversation away.