In Honor / In Memory Tribute Gift Notifications

Overview

Tribute gifts are often given in honor of or in memory of another person. After those gifts are received, institutions may want to notify the honoree, a family member, or another related individual that a tribute gift was made.

Slate queries can help identify the correct people to notify and return the gift details needed for a mail merge, Deliver document, or email notification.

This article walks through two common tribute notification workflows:

Before You Start

Before building tribute notification queries, determine your institution’s notification practices. For example:

• Which tribute occasion types should trigger notifications?
• Which gift statuses should be included?
• Should notifications be limited by gift date, fund, campaign, or donor segment?
• For memorial gifts, which relationship types should receive notifications?
• Does your institution track a custom relationship field indicating who should receive tribute notifications?
• Will the output be used for a mail merge, Deliver document, or email?

As you build these queries, it is strongly recommended that you rename joins and exports clearly. Tribute notification queries often include multiple Person joins, and clear naming helps prevent confusion between the honoree, deceased person, donor, and notification recipient.

In Honor Gift Notifications

Use this query when you want to notify a person that one or more gifts were made in their honor.

Suitcase ID: f423c3b0-8558-492b-b5f7-df67fd406ee5:slate-advancement-showcase

This query uses the Person base and returns one row per honoree.

How the Query Works

The main query starts from the Person base. Each row represents a potential honoree.

A subquery filter is then used to find qualifying tribute gifts and compare the person on the main query to the honoree associated with the gift.

Within the subquery filter, start from an independent subquery on the gift base and then join from Gift --> Gift Tribute --> Person.

In this structure, the joined Person represents the honoree.

The query then compares:

This comparison ensures that the main query only returns people who were honored by qualifying gifts.

Recommended Filters

Inside the independent subquery, add the gift filters that define which tribute gifts should be included.

Common filters include:

• Tribute occasion type, such as In Honor of
• Gift date
• Gift status
• Fund
• Campaign
• Donor segment
• Any other institution-specific criteria

For example, your institution may only want to notify honorees for posted gifts from the current month, or for gifts to specific funds.

Recommended Exports

Because the query uses the Person base, honoree information is available through direct exports. These exports may include:

• Honoree name
• Email address
• Mailing address
• Salutation
• Any other communication fields needed for the notification

To include gift details, create an independent subquery export that mirrors the same joins and filters used in the main query filter.

This is important: the export subquery should use the same gift criteria as the filter subquery. Otherwise, the query might correctly return the honoree but export gift details that do not match the intended notification criteria.

Common gift exports include:

• Donor name
• Gift amount
• Gift date
• Fund
• Tribute occasion
• Any internal gift reference details needed for review

If one honoree has multiple qualifying gifts, you may choose to concatenate those gift details into a single export value, or structure the results differently depending on your mail merge, Deliver document, or email process.

Result

The final query should return honoree information alongside the tribute gift details needed to send the notification.

Use this output to generate:

• A mail merge
• A Deliver document
• An email notification
• Another institution-specific acknowledgement process

In Memory Gift Notifications

Use this query when you want to notify a living relative or related individual that one or more gifts were made in memory of a deceased person.

This query uses the Relation base and returns one row per relationship record connected to the deceased individual.

Suitcase ID: 1bc4cfdb-5700-493d-bbc0-c669e424ade1:slate-advancement-showcase

How the Query Works

The main query starts from the Relation base. The relationship record represents the connection between the deceased person and the individual who may receive the notification.

At the base of the query, join from Relation --> Person. In this structure, Person represents the deceased individual.

Then add a subquery filter to compare and identify qualifying memorial tribute gifts using an independent subquery. Within that subquery, start from an independent subquery Gift base. Join from Gift --> Gift Tributes --> Person. The person in this case will be the tributed person.

The query compares the person that was joined in from the base of the query to the person associated with the tribute gift in the independent subquery:

This comparison ensures that the memorial gift is connected to the same deceased person represented by the relationship record.

Recommended Filters

Inside the independent subquery, add the gift filters that define which memorial gifts should be included.

Common filters include:

• Tribute occasion type, such as In Memory of
• Gift date
• Gift status
• Fund
• Campaign
• Donor segment

As with the In Honor workflow, these filters should reflect your institution’s notification practices.

Selecting the Notification Recipient

Because this query uses the Relation base, each row represents a relationship associated with the deceased person.

You can then filter which related individuals should receive notifications. Depending on institutional practice, this may include filters such as:

• Relationship type
• Spouse, child, parent, sibling, or other family relationship
• A custom relationship field indicating that the person should receive tribute notifications
• Active or preferred relationship indicators
• Other institutional criteria

The query may evaluate both linked and unlinked relationships. If you need information from a linked person record for the notification recipient, add a base join to Linked Record Person and rename that join clearly, such as Notification Recipient.

Recommended Exports

With the Relation base and a base join to Person, you can export information about both:

• The deceased person
• The relationship or notification recipient

Depending on how your relationships are configured, recipient information may come from the Relation itself or from the linked person record.

Useful exports may include:

• Deceased person name
• Notification recipient name
• Notification recipient address
• Notification recipient email
• Relationship type
• Salutation
• Donor name
• Gift amount
• Gift date
• Fund

To include gift details, create a subquery export that mirrors the same gift joins and filters used in the main query filter.

For example, if the main query only includes posted In Memory gifts from a specific date range, the gift export subquery should use those same criteria. This keeps the exported gift details aligned with the rows returned by the query.

Result

The final query will return the deceased person, the living notification recipient, and the memorial gift details needed for communication within a single row.

Use this output to generate:

• A tribute notification letter
• A Deliver document
• A mail merge
• An email notification
• A review list for staff before communications are sent

Video: Tribute Notifications

Best Practices

Rename Joins Clearly

Tribute notification queries often include several Person joins. Rename joins as you build the query so each one reflects its role.

Examples:

Clear naming makes it easier to build comparisons, select exports, review results, and troubleshoot issues later.

Keep Filter and Export Logic Consistent

When exporting gift details through a subquery export, use the same gift filters that were used to return the person or relationship row.

This helps prevent mismatches where:

• The query returns the correct recipient, but the export includes the wrong gifts.
• The export includes gifts outside the intended date range.
• The export includes tribute gifts with a different occasion type.
• The notification includes gifts that should not be part of the communication.

Decide Notification Rules Before Building the Query

The query structure identifies possible recipients and gifts, but your institution should define the business rules.

For memorial gifts especially, decide which relationships should receive notifications. Some institutions notify only spouses or next of kin. Others maintain a custom relationship field to indicate who should receive tribute notifications.

Review Results Before Sending

Before using results in a mail merge, Deliver document, or email, review sample rows to confirm:

• The correct person is being honored or memorialized.
• The correct recipient is listed.
• Gift details match the intended filters.
• Multiple gifts are displayed as expected.
• Donor names and funds appear correctly.
• No unintended relationship types are included.

Troubleshooting

The honoree or deceased person is not appearing

Check that the tribute gift is connected to the correct person and that the tribute occasion type matches your filter. Also review gift status, gift date, and any fund or campaign filters that may exclude the gift.

The query returns the right person, but the wrong gift details

Review the subquery export. The export should mirror the same joins and filters used in the main query filter. If the filter and export logic differ, the exported gift details may not match the intended notification set.

Memorial notifications are going to the wrong person

Review the Relation base filters. Confirm that the relationship record represents the intended notification recipient and that any relationship type or custom notification filters are correctly applied.

If you need information from a linked person record, add a join to Linked Record Person and rename it clearly as the notification recipient.

The query returns duplicate rows

For In Memory notifications, each row represents a relationship record connected to the deceased person. If multiple relationships qualify, multiple rows may appear. Refine relationship filters to include only the intended recipients.

For In Honor notifications, review whether the query is returning one row per honoree and whether multiple gifts are being concatenated or exported separately.

Gift details are missing from the notification output

Check the independent subquery export. Confirm that the gift joins are present and that the export subquery includes the same qualifying gift filters used in the query filter.

Frequently Asked Questions

Why does the In Honor query use the Person base?

The Person base allows the query to return one row per honoree. The independent subquery identifies qualifying tribute gifts and compares the honoree on the gift to the person on the main query.

Why does the In Memory query use the Relation base?

The Relation base allows the query to return one row per relationship connected to the deceased person. This is useful because memorial notifications are usually sent to living relatives or related individuals, not to the deceased person.

Can I use these queries for both printed and email notifications?

Yes. The query results can be used for mail merges, Deliver documents, email notifications, or other communication processes, depending on how your institution manages tribute notifications.

Do I have to concatenate multiple gifts into one export?

No. Concatenation is one possible approach when you want to display multiple gifts together for a single recipient. Your export structure should match your downstream process. A popular output format is a dictionary, which allows for easy liquid looping within deliver mailings, documents, and portals.

Can I limit notifications to only certain family members?

Yes. In the In Memory query, add filters to the Relation base to limit which relationships are included. You might filter by relationship type or use a custom relationship field that indicates who should receive tribute notifications.

Why is join naming so important?

These queries often include multiple Person joins. Without clear names, it can be difficult to know whether a Person join represents the honoree, deceased person, donor, or notification recipient. Clear names reduce errors when building comparisons and selecting exports.