Donor and Prospect Profiles

Prev Next

Overview

The Donor / Prospect Profile is a printable briefing view available in the Advancement Showcase environment. Institutions can use the Suitcase ID provided in this article to copy the Showcase profile into their own database environment, then customize it for local terminology, data sources, styling, sections, and workflows.

Suitcase ID: 685628e9-0a52-40d2-9028-514249a3b0b1:slate-advancement-showcase

This type of profile is built as a Slate portal, but users experience it as a profile document: they click a link or button from a person record, review the information, choose which sections to include, and then print or save the profile as a PDF.

This profile is designed to support common advancement workflows such as visit preparation, portfolio review, prospect strategy, leadership briefings, and donor research. Instead of maintaining multiple profile templates for different scenarios, institutions can start with a default profile and let staff tailor the printed output for the task at hand.

The Showcase profile includes biographical information, giving summaries, gift history, engagement activity, researcher notes, wealth and capacity indicators, open pledges, supported funds, and an AI-generated summary. Institutions can keep, remove, reorder, or modify these sections after importing the profile.

Image Image

Using the Donor / Prospect Profile

Opening the profile

After the profile has been Suitcased into an institution’s database, it can be opened from an individual person record using a link or button. In the Advancement Showcase Clean Slate environment, the link to the profile is on the Research tab and named Open Profile PDF.

When a user opens the profile from a record, Slate passes the person GUID to the portal. The profile layout stays the same, but the information displayed changes based on the record being viewed. This allows one reusable profile to display a different briefing for each donor or prospect.

The link should point to the institution’s own portal key and include the current record’s person GUID as a merge field. For example, if the portal key is profile, the link would follow this pattern:

/profile?key={{Person-GUID}}

In this example, profile is the portal key and {{Person-GUID}} is the merge field that supplies the GUID for the person record the user is currently viewing.

Your institution’s portal key may differ. Use the key for the portal in your own database environment and append ?key={{Person-GUID}} so the profile loads for the correct record.

Understanding the profile layout

The profile has two main areas:

  • Profile content: The donor or prospect briefing, including the sections configured by your institution.
  • Profile Configuration panel: A control panel that lets users choose which sections to include before printing.

The configuration panel includes checkboxes for available sections, along with Select All, Clear All, and Print Profile controls.

Checked sections remain visible on screen and are included when the profile is printed. Unchecked sections are hidden from the page and excluded from the printed version.

Foundational sections, such as the profile photo and basic biographical information, always display and do not appear in the configuration panel.

Choosing which sections to include

Before printing, users should review the Profile Configuration panel and select the sections that are useful for the current purpose.

For a quick meeting briefing, a user might include:

  • Giving Summary
  • AI Summary
  • Researcher Notes
  • Recent Gifts

For a more detailed strategy review, a user might also include:

  • Giving History
  • Engagement Metrics
  • Wealth and Capacity Indicators
  • Supported Funds
  • Open Pledges

This flexibility allows users to create a focused briefing without needing a separate report, query, or profile template for each use case.

Printing or saving the profile

After selecting the desired sections, click Print Profile.

When the profile is printed:

  • the Profile Configuration panel is hidden;
  • print buttons and other screen-only controls are hidden;
  • unchecked sections are excluded;
  • a confidential print header appears;
  • tables and profile sections use print-friendly styling; and
  • AI dashboard action links are hidden.

Users can print the profile or save it as a PDF from the browser’s print dialog.

Image

Confidentiality and appropriate use

Donor and prospect profiles may include sensitive advancement information, including giving history, research notes, engagement details, capacity indicators, relationship context, and AI-generated recommendations.

Printed or downloaded profiles should be treated as confidential institutional materials. The profile includes a confidential marking in the print header, and users should still follow institutional policies for storing, sharing, and disposing of donor or prospect information.

AI Summary

The out-of-the-box profile includes an AI Summary section powered by Slate’s AI dashboard functionality. This section provides a reusable, AI-generated briefing based on data available from the record. The AI Dashboard is configured separately and simply added as a component within the portal.

Depending on the dashboard prompt and the data made available to Slate AI, the AI Summary can include:

  • recent giving activity;
  • notable engagement or event participation;
  • giving capacity or research context;
  • important relationship details;
  • philanthropic interests;
  • suggested next steps; and
  • recommended follow-up strategy.

The AI Summary is intended as a briefing aid. It can help users quickly orient themselves, but it should not replace review of the underlying record details or professional judgment.

Administrator Guide

Starting from the Clean Slate example

This article includes a Suitcase ID that institutions can use to import the Advancement Showcase Donor / Prospect Profile into their own database environment.

The technical details below describe how the Showcase profile is built today. Institutions should treat this implementation as a working starting point: copy it through Suitcase, confirm that it works in the local environment, and then extend the patterns as needed.

After importing the Suitcase, administrators should review and customize the profile for their institution. Common updates include:

  • changing the portal key;
  • updating the print header logo, institution name, and confidential marking;
  • reviewing each section and confirming the appropriate data sources;
  • adjusting section labels and CSS classes;
  • adding, removing, or reordering profile sections;
  • updating the Giving Summary metrics;
  • configuring or refining the AI Summary dashboard; and
  • testing the record link from an individual person record.

To open the profile from a record, create a link that points to the imported portal. The URL should use the portal key from your environment and pass the current person GUID using ?key={{Person-GUID}}.

For example:

/profile?key={{Person-GUID}}

Replace profile with your portal key if your imported or renamed portal uses a different key.

How the Advancement Showcase Clean Slate profile is built

The Donor Profile is built as a portal with a Person scope. The portal is secured using the User security type, which means staff must be logged in to Slate to access the profile.

The portal uses a template as the wrapper for the profile. The template contains the HTML structure, CSS styling, print rules, configuration panel, and JavaScript that controls section visibility. The template is also where administrators update the shared design and behavior for the profile.

Because the shared design and behavior live in the template, administrators can add or change the actual portal content without recreating the styling inside each content area. Most section-level updates are handled by adding, removing, or editing portal parts and assigning the appropriate CSS classes.

This pattern is also what makes the profile extensible. Institutions can add new sections, remove sections that are not needed, or change the underlying queries and merge fields while continuing to rely on the same Template for layout, toggling, and print behavior.

Profile content is rendered inside the Template using the portal’s configured parts:

<main class="profile-container" id="donor-profile">
  {{content}}
</main>

Slate replaces {{content}} with the portal parts configured for the profile.

The Template includes:

  • HTML structure for the profile, configuration panel, and print header;
  • CSS for the web view, print view, profile sections, tables, Giving Summary cards, AI Summary output, and configuration panel; and
  • JavaScript that detects sections, builds the checkbox list, and shows or hides sections based on user selections.

The template CSS uses root-level variables, which makes it easier to adjust the Showcase design for institutional branding. Administrators can update these variables directly, or they can use Slate AI to help revise the Template colors to match their institution’s brand palette.

Image Image

Where profile data and merge fields come from

The merge fields used in the profile come from queries configured within the portal. These queries are associated with the portal’s default method and view and are filtered to the identity of the person record being viewed.

The profile uses several focused queries instead of one large query. This keeps the profile performant and organized. The queries run asynchronously, and because each query is scoped to the current person record, they return results quickly.

Some queries are person-based and correspond to individual profile sections, such as donor biographical information, researcher notes, engagement metrics, or giving summaries. This keeps each section easier to understand, troubleshoot, and modify.

Other queries use nodes to return lists of related data. Node-based queries are useful when a section needs to display multiple rows or values for the person, such as recent gifts, open pledges, or career history. In those cases, the query can start from the appropriate base, such as gifts or jobs, and return the related rows needed for a table or repeating section.

This structure gives institutions a clear pattern for extending the profile:

  1. Add or revise a portal query for the data needed.
  2. Filter the query to the current person record.
  3. Use a node when the section needs a list of related records.
  4. Add the merge fields or repeating output to the appropriate portal content section.
  5. Assign the section a meaningful CSS class so it appears correctly in the Profile Configuration panel.

Using multiple targeted queries also makes the backend portal easier to maintain. Administrators can see which queries support which sections and can update one section without needing to untangle a single large query that powers the entire profile.

How to make sections configurable

In the profile, each configurable section has a meaningful CSS class on the relevant portal part. The JavaScript uses that class as the section’s internal key. The label shown in the Profile Configuration panel is usually taken from the section’s heading.

Institutions extending the suitcased profile should follow the same pattern when adding new sections: create the portal part, add a clear heading, and assign a meaningful CSS class.

For example, a section with this class:

recent-gifts

and this heading:

<h2>10 Most Recent Gifts</h2>

appears in the configuration panel as 10 Most Recent Gifts.

If no heading is found, the script converts the class name into a readable label. For example, recent-gifts becomes Recent Gifts.

Adding or changing section classes

To extend the pattern, add section classes in the CSS class field for the relevant portal part. The exact field name varies by part type, but it is the field that controls the CSS class applied to the rendered part.

Use one or more classes separated by spaces.

Examples:

recent-gifts
open-pledges optional-section
name always-display

Use clear, machine-friendly class names that describe the section’s content. Examples include:

profile-photo
bio-data
giving-summary
ai-summary
researcher-notes
giving-history
engagement-metrics
wealth-capacity
recent-gifts
supported-funds
open-pledges

Avoid vague or layout-based names such as:

section-one
box-blue
left-column
data-section

The class should describe what the section contains, not where it appears or how it looks.

How section labels are determined

The label shown in the Profile Configuration panel is selected in this order:

  1. A data-profile-label value, if one exists.
  2. AI Summary, if the section is detected as Slate AI dashboard output.
  3. The nearest h1, h2, or h3 heading inside the section.
  4. A readable version of the section class name.

This allows administrators to keep class names short and consistent while still displaying clear labels to users.

For example:

<div class="career-history">
  <h2>Career History</h2>
</div>

The section key is career-history, but the user-facing label is Career History.

Section behavior classes

Default-on sections

A section with a meaningful class name appears in the configuration panel and is visible by default.

recent-gifts

The section will print unless the user unchecks it.

Optional sections

Add optional-section when a section should appear in the configuration panel but be hidden by default.

supported-funds optional-section
open-pledges optional-section

Use this for sections that are useful in some situations but not always needed.

Always-displayed sections

Add always-display when a section should always show and should not appear in the configuration panel.

profile-photo always-display
name always-display

Use this for foundational identity information, such as the profile image, name, and basic biographical data.

Initial Donor Profile section setup

The Donor Profile from Clean Slate uses the following section pattern:

Section Recommended class
Profile photo profile-photo always-display
Name name always-display
Contact Details contact-details
Primary Address address-details
Researcher Notes researcher-notes
AI Summary ai-summary
Giving Summary giving-summary
Giving by Fiscal Year fiscal-year-giving
Career History career-history
10 Most Recent Gifts recent-gifts
Open Pledges open-pledges optional-section
Engagement Metrics engagement-metrics optional-section
Supported Funds supported-funds optional-section

The AI Summary does not require the ai-summary class in order to work because Slate AI dashboard output is detected automatically. The class is still useful because it makes the portal easier for administrators to understand and maintain.

To make the AI Summary default off, use:

ai-summary optional-section

To make it always display and keep it out of the toggle list, use:

ai-summary always-display

Giving Summary Configuration

The Donor Profile's Giving Summary section uses special card styling to highlight key giving metrics, such as Lifetime Giving, Current Fiscal Year Giving, Most Recent Gift, and Largest Gift.

To apply this styling, add the following class to the section:

giving-summary

The section’s HTML should use the expected structure:

<h2>Giving Summary</h2>

<div class="stats">
  <div class="stat">
    <div class="stat-value">{{LifetimeGiving}}</div>
    <div class="stat-label">Lifetime Giving</div>
  </div>

  <div class="stat">
    <div class="stat-value">{{CurrentFYGiving}}</div>
    <div class="stat-label">FY Giving</div>
  </div>
</div>

Additional cards can follow the same pattern:

<div class="stat">
  <div class="stat-value">{{MostRecentGiftAmount}}</div>
  <div class="stat-label">Most Recent Gift</div>
  <div class="stat-meta">{{MostRecentGiftDate}} • {{MostRecentGiftDesignation}}</div>
</div>

The template CSS controls the layout, spacing, typography, and print styling. Avoid inline styles in the Giving Summary section unless a specific override is needed. Be sure to name the merge fields the same as the exports from the appropriate query.

AI Summary Configuration

The AI Summary section uses the Dashboard component within the portal. Administrators simply select an already configured Slate AI dashboard in order for the content to be merged in automatically.

Administrators can configure or revise the AI dashboard to interpret selected advancement data from the record and return a concise narrative summary. It may make sense to create a dashboard solely for the purpose of inclusion in this type of Donor or Prospect portal.

The profile automatically detects AI dashboard output when Slate renders GPT dashboard content inside the profile. The JavaScript looks for:

.gpt_container

When GPT output is detected, the profile can automatically:

  • style the AI-generated output;
  • label the section as AI Summary;
  • add an AI badge to the toggle list; and
  • hide GPT action links when printing.

Administrators do not need to manually add .gpt_container. That class is part of the rendered GPT dashboard output.

Print Header Configuration

The Showcase profile includes a print-only header with the institution logo, institution name, and confidential marking.

In the Template HTML, update this section for your institution:

<header aria-hidden="true" class="print-page-header">
  <div class="print-page-header__brand">
    <img alt="" class="print-page-header__logo" src="https://slate-advancement-showcase.technolutions.net/www/images/slate-logo.png" />
    <span class="print-page-header__institution">Slate University</span>
  </div>

  <div class="print-page-header__marking">
    Confidential Donor Profile
  </div>
</header>

Replace the logo URL and institution name as needed.

The header is hidden on screen and appears only when the profile is printed.

Font Awesome Icons

The Donor Profile uses Font Awesome for icons, such as trend indicators in the Giving Summary.

Confirm that the Template includes the stylesheet:

<link href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.5.1/css/all.min.css" rel="stylesheet" />

If icons do not appear, confirm that the stylesheet is present and that the user’s network allows the CDN to load.

Maintaining and Extending the Profile

Adding a section

To add a new configurable section using the Showcase pattern:

  1. Add the new content part to the profile portal.
  2. Add a clear heading, such as an h2, to describe the section.
  3. Add a machine-friendly CSS class to the part.
  4. Decide whether the section should default on, default off, or always display.
  5. Preview the profile.
  6. Confirm that the section appears in the Profile Configuration panel as expected.
  7. Print or save the profile as a PDF to confirm the print output.

Example default-on section:

planned-giving

Example default-off section:

planned-giving optional-section

Example always-visible section:

planned-giving always-display

Removing a section from the toggle list

If a section should remain visible but should not be toggleable, add:

always-display

Example:

bio-data always-display

If the section should not appear at all, remove or disable the corresponding portal part.

Making a section hidden by default

If a section should be available but hidden when the profile first loads, add:

optional-section

Example:

open-pledges optional-section

Updating the design

Most design updates should be made in the template CSS rather than inside individual content parts. From the portal landing page, administrators can select Edit Template to update the HTML wrapper, CSS, and JavaScript that control the profile’s shared structure and behavior.

The template CSS controls:

  • general page layout;
  • profile container styling;
  • the Profile Configuration panel;
  • headings;
  • tables;
  • profile image display;
  • Giving Summary cards;
  • AI Summary output;
  • print styling; and
  • the print-only confidential header.

Keeping design rules in the template makes individual content sections easier to maintain and helps the profile remain consistent over time.

How the JavaScript works

At a high level, the JavaScript:

  1. Finds the profile container.
  2. Looks for rendered Slate parts.
  3. Ignores utility classes such as part, section, optional-section, and always-display.
  4. Uses the remaining meaningful class name as the section key.
  5. Determines the user-facing label for each section.
  6. Builds a checkbox for each configurable section in the Profile Configuration panel.
  7. Shows or hides sections when users check or uncheck boxes.
  8. Watches for asynchronous GPT output and applies AI Summary behavior when .gpt_container appears.

This design allows many future updates to be handled by changing section classes rather than editing JavaScript.

Troubleshooting

A section does not appear in the Profile Configuration panel

Confirm that the portal part has a meaningful CSS class.

This is not enough:

section

Use a descriptive class such as:

giving-history
planned-giving

A section appears in the panel but should always show

Add always-display to the section.

Example:

profile-photo always-display

A section is visible by default but should start hidden

Add optional-section to the section.

Example:

supported-funds optional-section

The AI Summary does not show the AI badge

The AI badge appears when GPT dashboard output is detected. If the content loads asynchronously, it may take a moment.

The AI Summary appears, but the content does not look right

Review the AI dashboard configuration and prompt. The profile displays the AI dashboard output, but the quality, length, and structure of the summary are driven by the dashboard prompt and the data made available to Slate AI.

Best Practices for Extending the Showcase Profile

  • Use the profile as a briefing tool, not as a full replacement for the record.
  • Keep the default profile focused.
  • Use optional sections for deeper details that are not always needed.
  • Use always-display sparingly, reserving it for identity and context sections that should always appear.
  • Name sections clearly so future administrators can maintain the profile easily.
  • Avoid inline styling inside individual sections when possible.
  • Review both the web view and print view after making changes.
  • Treat AI-generated summaries as orientation and decision support, not as final judgment.
Still looking for what you need?