Education Cloud Multi Campus Configure

Education Cloud Multi-Campus Institutional Hierarchy Configuration

Guides Salesforce Administrators through the full lifecycle of an institutional hierarchy: initial creation AND ongoing maintenance. Parses organizational structure from documents, URLs, CSV, or text, then either builds the hierarchy from scratch or reconciles it against what already exists in the org — creating only the delta. Supports any number of hierarchy levels (e.g., System → Campus → College → Department, or System → Region → Campus → Division → Department) based on the input. Creates/updates Account records with parent-child relationships and Business Profiles for each level, derives materialized paths on the fly for semantic navigation, and validates the result.

Mechanism

Try `headless-360` first for every Account/BusinessProfile read or write — reads via dispatch_readonly, writes via dispatch (see references/mcp-invocation.md for call shape, response envelope, and per-step invocations). Probe with GET /services/data/vXX.0/limits before the first call: 2xx → route everything through it. Absent/4xx/5xx → probe other available transports (another Salesforce MCP server, or authenticated sf CLI) with the same read, use the first healthy one, and tell the user which transport is in use. None healthy → stop, ask the user to connect one; never fabricate a result.

Scope

• In scope: Parsing institutional structure from PDF/URL/text/CSV with any number of hierarchy levels (2+); new setup (create full hierarchy); update/reconcile (compare desired structure to the org's current hierarchy and apply only the delta — add new nodes, rename a node, move a node under a different parent); creating Account hierarchy with parent-child relationships via ParentId; generating Business Profiles for all levels; deriving materialized paths on demand from the parent chain; validating parent-child relationships; handling API errors during bulk create/update
• Out of scope: Deleting Account or Business Profile records (destructive — report extras, do not delete unless the user explicitly confirms per Step 7); single-level flat structures (no parent-child relationships); non-Education-Cloud account management; migrating field data between hierarchy nodes

Required Inputs

Gather or infer before proceeding:

• Organizational structure source (the desired structure): PDF document path, website URL, CSV, or plain text description
• System name: Top-level institutional system name (e.g., "Riverside Community College System")
• Hierarchy levels: All organizational levels present (Campus, College, Department, Division, Region, etc.) — infer from parsing, do not assume a fixed 4-level structure
• Mode hint (optional): Whether this is a first-time build or an update to an existing hierarchy. If not stated, detect in Step 4.
• Existing root (update mode only): The System (root) Account Id, so the current hierarchy can be traversed. A prior run of this skill prints this Id in its summary (Step 10).

Defaults unless specified:

• Record type for all accounts: resolve from org (do not hardcode) — see Step 3.5
• Business Profile creation: Enabled for every hierarchy level that lacks one
• Materialized path: Not a stored field — derived on the fly by walking the Account's ParentId chain to the System root when displaying a path
• Naming convention: Title Case with spaces preserved
• Deletion: Never automatic — extra nodes in the org are reported, not removed

If the user provides a complete hierarchy description or document, parse and confirm the structure before creating or changing records.

Workflow

All steps are sequential. Do not skip or reorder. If blocked, stop and ask for missing context.

1. Verify foundation prerequisites — Follow references/foundation_prerequisites.md: org edition, Lightning Experience, Education Cloud license, running user's Full Access assignment, Education Cloud Foundation enabled (self-heal via confirm-then-enable if off). Do not proceed to Step 1 until all checks pass.

1. Understand input format

• Ask user for organizational structure source: PDF path, URL, CSV, or text description
• If PDF: use Read tool to extract text content
• If CSV: read columns Name,LevelType,Level,ParentName (see examples/sample_hierarchy_input.csv for the expected shape; examples/sample_hierarchy_input_edgecases.csv shows duplicate names, abbreviations, and an orphaned parent reference)
• If URL: recommend to user that a trusted structured dataset (JSON/CSV) is the preferred input — web crawl results can be incomplete, inaccurate, or out of date, and some institutional sites block crawling. If the URL is not blocked it will still work. Then fetch and parse HTML to extract hierarchy information
• If the URL fetch is blocked or fails: do NOT silently substitute a different source (e.g. a search/research agent pulling from Wikipedia or another third-party site). Stop and ask the user for an alternative — a PDF, CSV, or pasted text from the institution's own site. The customer must never be left unaware of what their hierarchy was actually built from
• If text: parse directly from user's message

1. Parse desired hierarchy structure

• Extract System name (top level)
• Identify all hierarchy levels present (e.g., Campus, College, Department, Division, Region, etc.)
• Build parent-child relationships for each node based on nesting/indentation in source
• Store the desired structure as a tree: each node has Name, Level, and ParentNode reference
• For ambiguous structures, read references/hierarchy_parsing_rules.md for decision logic
• Do not assume fixed level names — use whatever level names appear in the source (Campus/Location/Site are equivalent, College/School/Faculty are equivalent, Department/Division/Program are equivalent)

1. Confirm desired structure with user

• Display extracted hierarchy in nested bullet format — see examples/hierarchy_visualization.md for the box-drawing template and formatting rules.
• Ask: "Is this structure correct?" (Yes/Make changes/No)
• If "Make changes": gather corrections and re-display
• If "No": stop workflow

3.5. Resolve Account RecordType from org

• Do NOT hardcode a RecordType Id or DeveloperName. Resolve the org's actual Account RecordType at runtime via describe (RecordType metadata like developerName/available isn't exposed through a plain Account SOQL query — describe is the correct source):
• GET /services/data/v68.0/sobjects/Account/describe via dispatch_readonly (see references/mcp-invocation.md)
• Read the recordTypeInfos array from body. Each entry has developerName, name, recordTypeId, available, defaultRecordTypeMapping.
• Select the institutional/business RecordType by developerName (varies by org, e.g. Business, Business_Accounts). Ignore the Master entry (developerName = "Master") — not selectable for records.
• Selection logic:
• If exactly one non-Master available:true RecordType → use it.
• If multiple candidates → ask user which developerName to use.
• If NO non-Master RecordType exists → missing prerequisite, not a dead end (common when this skill runs standalone, without a prior EDU setup skill). Follow references/account_recordtype_prerequisite.md: ask for/confirm a Label, confirm before creating, create via Tooling API, cold-verify available:true.
• Capture that entry's recordTypeId into a runtime variable recordTypeId (a resolved value from THIS org's describe response — never a literal copied into the skill). Use recordTypeId for every Account create in Step 6.

1. Determine mode: new setup vs. update

• Decide whether the org already has this hierarchy:
• If the user states it is a first-time build, or no System (root) Account exists → Case 1 (New setup).