What Is OrganizationRole Schema?

OrganizationRole is a Schema.org type for describing a role held by a Person or Organization within an Organization, with optional name, dates, and numbered position.

It sits between a relationship property and the underlying participant, allowing the graph to qualify who served, how, and when. Common patterns include a team member with a playing position, an association officer with a term, a board or advisory role, and an alumni relationship with a date. OrganizationRole inherits roleName, startDate, and endDate from Role and adds numberedPosition. EmployeeRole is its employment-specific subtype.

• Use OrganizationRole for a role within an organization.
• Add only role facts supported by the page.
• Use EmployeeRole when the relationship is specifically employment.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

Primary specification: Schema.org definition for OrganizationRole.

OrganizationRole adds meaningful context to an organization relationship without forcing every role to become employment.

Use OrganizationRole when a direct member, alumniOf, affiliation, or similar organization link needs role name, dates, or position context.

A simple current membership can stay simple. The role wrapper earns its complexity when the page explains a term of office, athletic position, chapter function, board seat, advisory appointment, alumni transition, or another time-qualified organizational relationship. Do not add a role node merely to wrap a Person name, and do not use it to hide uncertainty about whether a relationship is membership, employment, affiliation, volunteering, or governance.

1. Identify the underlying organization relationship.
2. Check whether role or time context is visible.
3. Use the direct property when no qualification is needed.
4. Add OrganizationRole only when it clarifies the relationship.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

Use the role wrapper when it makes the organization relationship more precise, not merely more complex.

OrganizationRole can qualify an Organization’s member property by placing the Person or Organization inside the role and adding roleName, dates, or position details.

For example, a sports team can use member with an OrganizationRole that in turn contains the Person, roleName, startDate, endDate, and numberedPosition. An association can represent an officer term similarly. The wrapper must preserve the original relationship: the organization has a member, and that member served in a role. Do not detach the Person, reuse one role for several unrelated members, or place dates on the Organization when they describe only the person’s term.

1. Start from the Organization and member relationship.
2. Use OrganizationRole as the member value when qualification is needed.
3. Place the Person or Organization inside the role’s member property.
4. Add supported role and date facts.
5. Reuse canonical participant and organization ids.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

A role-qualified member graph keeps the organization, participant, relationship, and term as separate facts.

OrganizationRole can qualify alumniOf when a Person’s relationship to an educational organization needs timing or other role context.

A Person can use alumniOf with an OrganizationRole wrapper that contains the educational organization and a relevant date. The semantics of dates require care: a startDate on the alumni relationship may reflect when alumni status began, often after leaving the institution, rather than the first day of study. If the page simply states an alma mater, a direct alumniOf relationship may be clearer. Do not manufacture attendance dates or imply graduation when the source only supports attendance.

• Use direct alumniOf for a simple alumni relationship.
• Use OrganizationRole when alumni timing is material.
• Interpret role dates according to the relationship being qualified.
• Preserve the canonical educational organization identity.
• Avoid unsupported graduation claims.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

Role-qualified alumni markup should clarify timing without rewriting attendance history or inventing graduation facts.

OrganizationRole covers roles within organizations broadly, while EmployeeRole is the narrower subtype for employee relationships and adds salary-related properties.

A volunteer officer, board position, association role, athlete position, advisor, or club member may fit OrganizationRole without implying employment. A staff or executive role can use EmployeeRole when employment is established and role detail is needed. Choose the narrowest accurate type. Do not use EmployeeRole merely because a role has a title, and do not use generic OrganizationRole to avoid acknowledging clear employment when the page is an employee profile.

• Use OrganizationRole for non-employment organization roles.
• Use EmployeeRole for verified employee relationships.
• Do not infer employment from a title alone.
• Keep salary fields out of generic organization roles.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

Use the broader role for organization participation and the employee subtype only when employment is a verified part of the claim.

roleName, startDate, endDate, and numberedPosition should describe the specific role at the precision and meaning supported by the page.

roleName accepts Text or URL and should use a recognizable function rather than an internal code. Dates use Date or DateTime in ISO 8601 format; a year is better than an invented full date when only the year is known. numberedPosition is a Number associated with the role, such as an athlete’s jersey number. It is not a ranking, sort order, employee id, membership number, or list position unless the organization explicitly uses it that way.

1. Use the public role label.
2. Use ISO-formatted dates at known precision.
3. Omit endDate for an active role.
4. Use numberedPosition only for a real role number.
5. Keep internal ids and display order out of the property.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

Role qualifiers should preserve known meaning and precision rather than filling every available field.

Model each materially distinct role as a separate OrganizationRole when function, organization, term, or participant differs.

A person may serve two terms, hold several positions, move between chapters, or maintain simultaneous roles in different organizations. Combining all roleName and date values in one wrapper makes it unclear which facts belong together. Reuse the same canonical Person and Organization ids while giving each meaningful role its own context. Historical roles should have an endDate or be presented clearly as past; current roles should not inherit dates from a former term.

1. Define role boundaries by organization, function, and term.
2. Create one wrapper per meaningful role.
3. Attach the correct participant and organization ids.
4. Separate current and completed terms.
5. Merge duplicates produced by templates or locales.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

Separate role nodes should make a timeline clearer while canonical identities keep the people and organizations unified.

Common mistakes include adding role wrappers without purpose, using EmployeeRole for non-employees, inventing dates, misusing numberedPosition, disconnecting the participant, and duplicating role identities.

Teams may wrap every member even when no qualifier exists, place a job vacancy inside OrganizationRole, treat list order as numberedPosition, or create one role with several people. Former roles may lack endDate and appear current. Localized and embedded templates can create duplicate Organization and Person ids. Validation can catch some malformed structures but cannot determine whether a role existed, whether it was employment, or whether a term is current.

• Empty role wrapper around a direct relationship.
• EmployeeRole used without employment evidence.
• JobPosting replaced by a role node.
• Display order used as numberedPosition.
• One role reused for unrelated participants.
• Former role shown as current.
• Duplicate Person, Organization, or role ids.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

A useful OrganizationRole adds verified role context; anything else should be simplified, corrected, or removed.