Explanation

The Education Data Architecture (EDA) is built on a specific "Account Model" (typically the Administrative or Household model) that relies on a 1-to-1 or 1-to-many relationship between Standard Accounts and Contacts.

Architectural Conflict: Person Accounts essentially "merge" the Account and Contact objects into a single record. EDA's core automation—such as the TDTM (Table-Driven Trigger Management) framework, address management, and reciprocal relationships—is designed specifically to work with the standard Contact object linked to an Account.

Official Stance: Salesforce.org documentation explicitly states that Person Accounts are not supported within EDA. While you can physically install the EDA package into an org where Person Accounts are enabled, the EDA functionality will not apply to Person Account records, and using them alongside EDA can lead to significant technical issues, data duplication, and broken automation.

The Recommendation: For institutions already using Person Accounts, the consultant must discuss a migration strategy to move that data into the EDA-supported Administrative or Household Account model before fully adopting EDA features.

Incorrect Answers

B. A support ticket is required to disable Person Accounts:
Why it's incorrect: This is a common misconception, but it is actually a "trick" answer. Once Person Accounts are enabled in a Salesforce org, they cannot be disabled, not even by Salesforce Support. The action is permanent and irreversible. If an institution wants to move away from them, they must hide the record types or migrate to a new Salesforce instance.

C. Person Accounts can only be merged with Administrative Accounts:
Why it's incorrect: This is technically false. In the Salesforce platform, Person Accounts can only be merged with other Person Accounts. They cannot be merged with Business Accounts or the specific "Administrative Accounts" used by EDA.

References
Salesforce Help: EDA Limitations and Extension Options (Explicitly states: "Person Accounts Are Not Supported")
Salesforce Help: Cannot Disable Person Accounts
Trailhead: Education Data Architecture Basics - Install EDA

Explanation:

In Education Data Architecture (EDA), the Attribute object is specifically designed to track additional characteristics, preferences, or requirements associated with a Contact (student). This makes it the ideal solution for the Accessible Education office to record and manage disability accommodations and accessibility needs.

The Attribute object allows institutions to:

- Record student-specific accommodations (e.g., extended test time, note-taking support, accessible classroom seating).
- Associate multiple attributes with a single Contact, ensuring flexibility for students who may require more than one accommodation.
- Maintain historical records of accommodations over time.
- Use declarative tools (reports, dashboards, flows) to monitor and manage accessibility services.

This approach leverages EDA’s native functionality, avoids unnecessary customization, and ensures upgrade-safe configuration.

❌ Why not the other options?

A. Use the Behavior Response object
Behavior Response is used for tracking student behavior incidents and responses, not accessibility accommodations.

C. Configure a custom object
While possible, creating a custom object duplicates functionality already provided by the Attribute object. It adds unnecessary complexity and maintenance overhead.

D. Create custom fields on the Contact object
Custom fields could capture a few accommodations, but they lack flexibility for multiple or changing needs. Attributes are more scalable and structured.

🔗 References
Salesforce Help: EDA Attribute Object
Trailhead: Education Data Architecture Basics

Explanation:

Pathways is a specific, visual component within Education Cloud designed to help students and advisors map out and visualize academic journeys. It provides a clear, step-by-step graphical representation of degree requirements, course sequences, milestones, and optional tracks (like concentrations or minors). This directly addresses the department's need to "picture academic options more clearly and visualize degree requirements."

Why not C. Path? "Path" is a general Salesforce feature (often related to guided processes, sales stages, or onboarding) and is not the Education Cloud-specific component for visualizing academic degree plans. It lacks the academic structure and data model integration (Programs, Courses, Requirements) that Pathways provides.

Why not B. Success Plans? Success Plans are a core feature of Student Success Hub used to create structured, actionable plans for student support (e.g., a plan with tasks, goals, and milestones for academic probation, career preparation, or wellness). While incredibly valuable for advising, they are not the primary tool for visually mapping out the structured academic curriculum and degree requirements themselves.

Key Concept & Reference:

Pathways is an Education Cloud component that transforms a Program Plan into a visual, interactive flowchart. It shows required and elective courses, prerequisites, and progression, helping students understand "what to take and when."

This functionality is central to the academic advising and program management capabilities of Education Cloud, as documented in the Education Cloud Implementation Guide and Salesforce Trailhead modules on "Manage Student Pathways."

Explanation:

Student Success Hub (part of Education Cloud) provides native appointment scheduling features, including the Scheduling Wizard, Advising Pools/Support Pools, and integration with Experience Cloud portals for student self-scheduling.

However, Student Success Hub does not include native bidirectional calendar sync with external systems like Google Calendar (or Outlook/Exchange). Faculty advisors cannot automatically see student appointments reflected in their personal Google calendars, nor can their Google availability block times in Student Success Hub scheduling—unless an integration is added.

The standard solution for this requirement is to recommend a third-party AppExchange app specialized in calendar synchronization. Common options include:
- Calendly (with Salesforce integration flows)
- Chili Piper
- Cirrus Insight
- Revenue Grid
- Custom connectors via MuleSoft or other middleware

These apps enable real-time or near-real-time sync of appointments created in Student Success Hub to faculty Google Calendars (and often pull availability back into Salesforce Scheduler-like flows).

Why the other options are incorrect:

B. Salesforce Scheduler
Salesforce Scheduler (formerly Flow-based scheduling) is a separate licensed product focused on service/appointment scheduling (e.g., for banking, retail). It supports Outlook and Google Calendar sync natively, but it is not integrated with Student Success Hub. Student Success Hub uses its own advising-specific scheduling engine (Support Pools, appointment types, etc.), and Scheduler cannot be layered on top without significant custom work. It is not the recommended path for Education Cloud advising scenarios.

C. Einstein Activity Capture
Einstein Activity Capture (EAC) syncs emails and calendar events from connected Gmail/Outlook accounts into Salesforce Activity history for visibility on records. It is one-way (external → Salesforce) and designed for logging past events, not for creating or syncing future appointments bidirectionally. It cannot push Student Success Hub appointments out to Google Calendar or block advisor availability.

References:
Salesforce Help & Trailhead: Student Success Hub scheduling documentation confirms no native Google Calendar integration; recommends third-party tools for external calendar sync.

Explanation:

The Advancement office’s requirement is clear: they want a declaratively configured, public-facing form that allows external users (such as alumni, donors, or students) to submit information that will automatically create records in Salesforce. This type of functionality is not provided by core automation tools like Process Builder or Email-to-Case. Instead, it requires a solution that can expose a form to the public and integrate directly with Salesforce.

The best recommendation is to use an app from the Salesforce AppExchange. The AppExchange offers several declarative, no-code form-building solutions (such as FormAssembly, Fonteva, or other nonprofit-focused apps) that allow organizations to:
- Build public-facing forms without custom development.
- Map form fields directly to Salesforce objects and fields.
- Automatically create or update records in Salesforce when a form is submitted.
- Apply validation rules, conditional logic, and security controls.
- Ensure compliance with data privacy and security standards.

This approach is declarative, scalable, and aligned with Salesforce best practices for Advancement offices, which often need to collect donations, event registrations, or alumni updates through public forms.

❌ Why not the other options?

B. Process Builder
Process Builder is an internal automation tool. It cannot create public-facing forms or accept external submissions.

C. Email-to-Case
Email-to-Case is designed for service teams to convert incoming emails into cases. It is not suitable for Advancement use cases like donor forms or alumni engagement.

🔗 References
Salesforce AppExchange: FormAssembly for Salesforce
Trailhead: AppExchange Basics