nonprofit-volunteer-management-model-get

Nonprofit Cloud Volunteer Management — Data Model Knowledge

This skill explains why the Volunteer Management object model is shaped the way it is: why so many entities are borrowed from other clouds, how fields are gated by permissions, and how the pieces combine into features. Object and field definitions give the fields; this skill gives the intent, so an agent can map a user's goal ("track completed volunteer hours", "require approval before signup", "cap a shift at 10 people") onto the right entities and fields.

Hard rules

• Never delete records. No delete, rollback or cleanup of any kind. If a write fails part-way, report what was created and what wasn't; never undo it.
• Never act on NPSP or Volunteers for Salesforce (V4S). That legacy package is unsupported here. Say so and stop.
• No acronyms or internal labels in what the user sees. Write out Volunteer Initiative, Job Position, Job Position Shift, Job Position Assignment, Position Qualification, Job Position Qualification, Data Processing Engine, and "out of the box". Never show internal step or section labels.
• No org operations. This skill answers from its references; it never reads or writes an org.

Scope

Only the entities in the Volunteer and Volunteer Management sections of the model, plus the Address that a Location points at. Benefit is referenced by one in-scope bridge entity (PositionBenefit) but belongs to Program Management: treat it as an external dependency and never model it.

Non-goals:

• Planning or designing a program, or deciding which records a program needs → nonprofit-volunteer-management-structure-generate.
• Creating or reusing records, or how to fill in a field when creating one → nonprofit-volunteer-management-records-create.
• Turning Volunteer Management on in an org.

Required Inputs

The user's question. No org connection is needed.

Answering Workflow

1. Identify the concept. Work out which feature or entity the question touches: matching,

capacity, rollups, approval, the benefit bridge, the hierarchy, or a single entity or field.

1. Read the matching reference. Features and how entities connect → references/relationships.md;

one entity's purpose, fields and gotchas → references/entities.md; the design principle behind a choice → references/themes.md.

1. Answer only what was asked, briefly. Lead with the direct answer, then only the detail that

earns its place. Don't tour the model or add features the user didn't ask about. If the user narrows the question ("just the permission model"), stay inside that boundary; mention a neighbouring mechanism only if the answer depends on it, in one line. Keep an answer to a few short paragraphs or bullets, about 300 words. Give each entity one line; list its fields, picklist values or a summary table only when the user asks for them.

1. Mention caveats, don't list them. If the topic has a "shipped but not configured" caveat (see

"Mechanism shipped, configuration is the customer's" below), say that one exists and offer to show it. Give the detail only if the user asks.

Rules / Constraints

The hard rules above apply to every answer. In addition:

The three things to understand first

1. Reuse over new entities — and Account is a "hero" entity

Most Volunteer Management entities are not native. They are borrowed from other clouds, and Volunteer Management adds a small number of fields gated behind its permissions. This is deliberate: Account is a "hero" entity that Salesforce makes hard to extend, so product data hangs off related entities rather than new Account or Contact fields. Volunteer Management adds no fields to Account or Contact. For volunteer data, look for the related entity.

A borrowed entity's Volunteer Management fields are the only part of it that Volunteer Management cares about. references/entities.md names every one.

2. The permission model mirrors an authenticated boundary

Records are gated by four permission expressions that map to three kinds of user:

A volunteer can sign up before they have an account. A guest exists only as a Contact; once they create or convert to a Person Account they are an authenticated volunteer. This boundary is the most important pattern in the model: entities that store a volunteer's own data (availability, credentials, engagement history) require an Account; the public signup path accepts a bare Contact.

The volunteer is a Person Account, so Person Accounts must be enabled. The "Business Account" box in the diagram is just how Salesforce draws Person Accounts.

&& (AND) gating across two clouds marks a deliberate cross-product bridge (Volunteer Management && Benefit Management), unlike the usual || (OR) gating of plain reuse. See references/themes.md T20.

3. Mechanism shipped, configuration is the customer's

Volunteer Management often ships the field or hook but not the behaviour. These are the caveats to offer when a question touches them:

• Engagement rollups (4 fields on DonorGiftSummary, 6 on VolunteerInitiative) exist but are

empty until the customer builds and schedules a Data Processing Engine definition.

• Status on Volunteer Initiative, Position, Job Position and Job Position Shift ships with

out-of-the-box values that admins can change. Each lifecycle is independent: nothing moves one entity's Status when another's changes. Stage Management automation is the customer's to set up.

• `Position.IsInternalApprovalRequired` does nothing on its own. The customer wires Salesforce

Approvals to it; approval moves the Job Position Assignment's Status.

• Shift capacity is counted, never enforced. Assignments are counted onto the shift and

RemainingCapacity is a formula, but nothing blocks a signup when a shift is full.

• `ConstituentRole.RoleType` ships with "Volunteer" (plus Donor, Philanthropic Prospect and

Participant), so the customer doesn't need to add it.

The model at a glance

• Who: Person Account (authenticated volunteer) or Contact (guest). Marked as a volunteer by

ConstituentRole. Engagement totals sit on DonorGiftSummary (a volunteer is assumed to be a likely donor).

• What they can do: PersonLocationAvailability (when and where), PersonCompetency

(skills), PersonExamination (credentials). Matching uses availability and PersonCompetency; PersonExamination is for a manager's own review, not matching.

• The work: Position (reusable template) → JobPosition (a concrete posting, optionally at

a Location) → JobPositionShift (a dated occurrence) → JobPositionAssignment (a person doing it on a day; the source of truth for hours).

• Requirements on the work: PositionQualification and JobPositionQualification point at a

Competency or an Examination. Matching uses QualificationLevel on Competency qualifications. A Job Position's own qualifications and its Position's qualifications are checked together, keeping the higher level per Competency. Nothing is copied from the Position to the Job Position.

• Organizing anchor: VolunteerInitiative — an optional, self-referencing top-level parent.
• Integrations: PositionBenefit bridges to Benefit Management (volunteers provide a service

that beneficiaries receive as a Benefit); Approvals and Stage Management hook into the Status fields.

Output Expectations

• A direct answer in plain language, naming the entity and field API names the user needs.
• Only the entities and features the question needs, about 300 words, one line per entity. Say each point once: no restated summary, no closing recap, and no list of follow-up topics.
• When a caveat applies, one line saying it exists and offering to show it.
• When the request is out of scope, name the sibling skill that handles it, or say that NPSP / V4S is

unsupported and stop.

Cross-Skill Integration

Those skills come back here only for what an entity or field means.

Reference File Index