When implementing Nonprofit Cloud (NPC), the transition to Person Accounts is a foundational architectural choice. While Person Accounts effectively combine Account and Contact attributes into a single record to represent an individual, they come with specific technical constraints that consultants must navigate during the solution design phase.

One significant limitation involves field references in formulas. Because a Person Account is technically a hybrid, it utilizes fields from both the Account and Contact objects. However, from a metadata perspective, a formula created on the Account object (which is the parent for the Person Account) cannot directly reference a custom formula field that resides on the Contact object. This is because the system does not allow "cross-object" formula references between the Account and Contact layers within the Person Account record structure.

To work around this, a consultant must often recreate the logic directly on the Account object or use a standard (non-formula) field on the Contact that is populated via Flow, which can then be surfaced on the Person Account.

Other limitations and considerations include:

Opportunity Contact Roles (Option C): This is actually supported. In fact, Person Accounts are frequently used as Contact Roles in donor management and gift processing.

Activities (Option B): Person Accounts fully support Tasks, Events, and being invited to meetings, just like a standard Contact or Lead.

AppExchange Compatibility: Not all third-party apps are "Person Account ready." A consultant must verify that any external integrations or packages can handle the IsPersonAccount field and the unique record type structure.

Understanding these limitations ensures that the data model supports the organization’s reporting and automation needs without hitting architectural roadblocks late in the implementation.