Week 21: Scoped Applications & App Engine Studio

1. Creating an Application Scope

Recall Week 1's definition: a scope is a namespace an application's tables and scripts live in. Creating a new application (Studio → Create Application, or System Applications → Studio) generates a scope identifier like x_yourco_myapp — every table, Script Include, and widget you build from here on lives inside that namespace, distinct from the global scope everything up to this point has implicitly used.

2. Cross-Scope Access

By default, script in one scope cannot directly read private APIs or tables in another scope — this is a deliberate security boundary, protecting a vendor's or another team's application from being reached into and broken by code they don't control. Where cross-scope access is genuinely needed, it has to be explicitly granted (Application Access records, or marking specific APIs/tables as accessible from other scopes) — never assumed by default.

Why this matters for the capstone specifically

Your capstone app will need to read incident/task data (global scope, from Weeks 4–20) from your own new scope. GlideRecord queries against tables in another scope generally work for read access without special configuration, but writing to another scope's tables, or calling another scope's Script Includes directly, is exactly where you'll hit — and need to understand — cross-scope restrictions.

3. Designing Tables in App Engine Studio

App Engine Studio (AES) is a newer, more guided interface for designing an application's data model — tables, fields, relationships — sitting on top of the same underlying sys_db_object/dictionary mechanics from Week 2, but with a visual, less ceremony-heavy workflow than manually creating dictionary entries one at a time. It's a good entry point for scaffolding a new app's tables quickly; Studio remains the tool for everything AES doesn't cover (custom scripts, ACLs, widgets).

4. Planning the Capstone's Data Model

The capstone (Weeks 25–26) is an "Equipment Request" scoped application — deliberately close to the catalog exercise from Week 15, but built as a fully custom app instead of a catalog item, so every layer (table design, ACLs, Business Rules, a Flow, a Service Portal frontend) is something you built rather than configured on top of an out-of-box process.

capstone data model — plan now, build in Week 25

x_yourco_equip_request (extends task, so it inherits state/priority/assignment)
  - requested_item      (string)
  - quantity            (integer)
  - justification        (string, multi-line)
  - approval_status      (choice: Pending / Approved / Rejected)

x_yourco_equip_catalog (a simple lookup table of requestable items)
  - item_name           (string)
  - available_stock      (integer)

You won't build these tables yet — this week ends with a plan, not working code; Week 21's exercise is deliberately about the design decision, since a rushed data model is the single most common source of painful rework in Weeks 25–26.

5. Hands-on Exercise

Hands-on

Create your capstone's scope and scaffold its tables

Requirements:

Create a new scoped application (name it something like "Equipment Requests"), noting the generated scope identifier.
In App Engine Studio, create the equip_request table extending task, with the fields listed above.
Create the equip_catalog table with its two fields, and seed it with 3–5 sample rows.
Add a reference field on equip_request pointing at equip_catalog (so a request references a specific catalog item, dot-walkable per Week 2), and write down — as a comment or a short doc, not code yet — which fields you expect ACLs to restrict in Week 25.

6. Knowledge Check

Four quick questions. Expand each to check your answer.

What does creating a new scoped application actually create, mechanically?

A new namespace (scope), identified by something like x_yourco_myapp, that every table, Script Include, widget and other artifact you build from that point on lives inside — distinct from the global scope, and distinct from any other application's own scope.

Why can't script in one scope freely read private APIs or write to tables in another scope by default?

It's a deliberate security boundary protecting applications from being reached into and broken by code outside their control — without it, any scoped app on an instance could interfere with any other, including vendor-provided applications the customer doesn't maintain themselves.

What is App Engine Studio's relationship to the dictionary/table mechanics covered in Week 2?

AES is a newer, more guided visual interface for designing tables, fields and relationships, but it operates on the exact same underlying sys_db_object/dictionary mechanics from Week 2 — it's a faster on-ramp to scaffolding a data model, not a different data model underneath.

Why does the capstone's Week 21 module end with a data-model plan rather than working code?

A rushed or poorly thought-through data model is the most common source of painful rework once ACLs, Business Rules, a Flow and a Service Portal frontend are all built on top of it in Weeks 25–26 — deciding the table structure deliberately now, before building on it, avoids having to unwind those dependent layers later.