Skip to content

Step 1 — Accounts

The first step asks: which observing grants fund this observation?

You don't pick an "account" directly — you pick one or more observing grants, each of which is tied to an account (and through that, to a set of queue access grants on specific telescopes). Grants are the finest-grained unit of "I have permission to spend this much time here," and the editor surfaces them grouped by account name and kind so you can see what's available at a glance.

For the model itself, see Observing accounts.

What's shown

The accounts step shows every grant the observation's owner can spend against — pulled from the owner's creator graph through the API. Each grant row carries:

  • Account name and kind — which account it belongs to (root or subaccount, owner / member / group / delegated).
  • Queue access — the telescopes and observing queues the grant reaches. This is the practical question: "if I pick this grant, which telescopes can fulfill my observation?"
  • Quota headroom — when the grant or its parent account has one or more quotas attached, the remaining headroom against each one (e.g. "350 of 500 weekly credits left" plus "8 400 of 10 000 lifetime credits left"). Grants without quotas show "unlimited."
  • A checkbox — you can pick more than one grant. The scheduler treats the union of selected grants as the eligible queue set for the observation.

Subaccounts inherit their parent's queue access, so picking a subaccount grant gives you visibility into the same telescopes as the parent.

You must pick at least one grant before you create the observation.

Why grants and not accounts

The reason this step asks for grants rather than accounts is that an account is a container — it bundles grants but doesn't, by itself, say you have permission to spend its time. Grants are what say "this user, in this role, can submit observations against this part of this account."

In most workflows the distinction doesn't matter — you only have one grant per account, and "pick the account" and "pick its grant" are the same action. The distinction becomes load-bearing when:

  • An account spans multiple grants with different quotas (a consortium with per-member quotas, for example).
  • You hold member-level access to an account without owning it, and the owner has also granted delegated access elsewhere.

Common shapes

  • One grant on one personal account — the default for most individual users.
  • One grant per organization you're a member of — show up as separate grants in the picker; pick whichever the observation should bill against.
  • A group grant — granted to a group you're a member of (a class, a research group). Submission rights flow through the group.
  • Multiple grants for redundancy — pick more than one when you want the scheduler to consider eligible telescopes from a broader set.

Component reference

What changes between steps

When you advance to step 2 (target), the picked grant set is written back to the observation. The grant set narrows what telescopes are eligible — and therefore which target capabilities matter — but doesn't yet constrain the target itself. That comes later.

← Back to editor overview · Step 2 — Target →