Integrated Profile Management

Profiles

• Profile - A record in CommunitySuite that captures all information about one entity, including notes, donations, grants, and fund advisor information. Types of profiles include Individual, Organization, and Household. When this article says "profile," it means a person or org profile.
• Organization Profile - Types of profiles used for an organization (nonprofit, university, business, etc.). All grant applicants in GLM must be associated with an organization profile. Think non-person entities; no individuals.
• Profile Designation - An additional layer on a profile that enables specific types of transactions or information (for example, Donor, Grantee, Vendor, Student, Fund Advisor, User). A single profile can hold multiple designations.
• Is School Designation - A specific designation applied to an organization profile in CommunitySuite that identifies it as a school for scholarship processing in SLM. Only the profile with this designation will appear in the SLM integrated payee field drop-down menu. Note: profiles with the "Is School" or "Is Student" designation are not searchable on the Fund Advisor Portal.

Org Structure and Integration

• Parent Profile - An organization profile at the top of a profile hierarchy. Grant and donation activity from both the parent and its child profiles roll up and display on the parent for consolidated reporting.
• Child Profile - An organization profile linked under a parent. Used to represent departments, programs, chapters, or sub-entities. Allows detailed tracking while still rolling up to the parent.
• Linked/Synced Profile - A profile in CommunitySuite that has been connected to a corresponding organization or user in GLM or SLM. These terms are used interchangeably. Linked profiles share field data between systems per integration rules. Note: GLM and SLM only communicate with each other through CommunitySuite; there is no direct GLM-to-SLM connection.

Addresses

• Primary Address - The main address on a profile in CommunitySuite. All communications and payments default to this address if no other address type is specified.
• Integrated Address - The address line in CommunitySuite that is linked to and synced with GLM or SLM, identified by a GLM/SLM icon next to the address. Only one address per profile can be integrated.
• Pay Address - The address in CommunitySuite designated specifically for sending payments (checks). This should be kept separate from the integrated address so payment routing is not automatically overwritten by applicant or GLM updates.

Duplicates

• Duplicate Profile - Two or more profile records in a system representing the same entity. Duplicates can be merged, but merging cannot be undone.
• Merge - The action of combining two profile records into one. The primary profile is the record that remains; the non-primary profile's data is absorbed into it.
• Merge Queue - A CommunitySuite-only feature (Tag Merge) that holds proposed profile merges for staff review and approval before the merge is finalized. GLM flags duplicates based on EIN only. SLM has no automatic duplicate detection. CommunitySuite flags duplicates based on matching name, email, or phone, each evaluated independently.

Organizations often interact with organizations in multiple ways, which requires careful profile structure for clean reporting across CommunitySuite, GLM, and SLM. Before connecting your databases, follow these three steps in order:

1. Clean up duplicates first. Clean up duplicates in each system independently before linking anything.
2. Make a plan. Decide how profiles will link across platforms and how grantees will interact with the software.
3. Keep address management top of mind. Determine your system of record for addresses before you start syncing.

A parent/child org structure in CommunitySuite lets you track grant and donation activity at a granular level while still rolling everything up to a single parent profile for consolidated reporting.

How to Structure Parent and Child Profiles

• Parent profile: Use the profile with the most legacy history, especially if migrating from a prior system where all activity was combined. This consolidated history is preserved and visible on the parent. 
• Child profiles: Create one new child profile per department, program, or sponsored organization. Organizations that are not yet 501(c)(3) can be sponsored under a parent; once they receive accreditation, they can be unlinked and will retain their full grant history.

National Organization Structure Example

An example of a parent/child relationship across a national organization is the Red Cross that has several regional/local/offices/branches. 

• The Red Cross organization profile serves as the parent, keeping combined grant history in one place.
• Every regional/local/office/branch gets its own standalone org profile as a child.
• This allows fund advisors to search for and grant to their local branches/chapters and allows the organization to report on combined giving across all the branches and include the national branch or exclude the national branch. 

University and Scholarship Structure Example

For organizations working with universities in SLM, the parent/child structure is especially important:

• The main university organization profile serves as the parent, keeping combined grant history in one place.
• Every department, including each financial aid office or payment location, gets its own standalone org profile as a child.
• Only the qualifying profile receives the "Is School" designation that reads into SLM. This keeps financial aid offices from being searchable in the Fund Advisor Portal, preventing fund advisors from granting directly to financial aid offices and allowing them to grant instead to the department or school of their choice.
• Recommendation: If a migrated profile already exists with combined history, keep it as the parent. Create brand-new CommunitySuite profiles for each additional department going forward to keep activity clean and trackable.

Pros and Cons

Below are the pros and cons to consider before adopting the parent/child structure.

There is no one-size-fits-all answer for address management. It depends on your organization's setup, staff capacity, and your designated system of record. Consider these questions first:

• Do you have a dedicated database management team?
• Who decides when to update the pay address vs. the primary address?
• Which system is your official system of record for 990 reporting?
• Are address standards documented and understood by all staff?

When to Update Addresses in GLM

GLM supports one address per organization profile. Any update made in GLM flows automatically to CommunitySuite with no review, pause, or alert by default.

• Applicant self-service (opt-in): Allows organizations to update their own address in GLM. Best suited for small organizations with high grant volume. This setting is off by default and can only be enabled by Foundant Support. It is recommended to always enable opt-in auto-email alerts to catch any changes.
• GLM organization staff updates: Ideal when grant staff work only in GLM and not CommunitySuite. Staff can add address-verification questions to applications for real-time accuracy. Updates flow automatically to CommunitySuite since the address is integrated.

When to Update Addresses in CommunitySuite

CommunitySuite supports multiple address types, making it the more capable system for complex address management.

• Physical address, mailing address, and pay address can all be managed independently in CommunitySuite.
• Only one address per profile integrates with GLM. Additional addresses are invisible to GLM applicants and must be maintained in CommunitySuite only.
• Staff who manage pay addresses, especially for scholarship payments, must have CommunitySuite access.

This is typically why CommunitySuite becomes the system of record for addresses: it handles nuances that GLM cannot.

How Address Integration Works: A Note on a Key Exception

In most scenarios, the integrated address is fully synced between CommunitySuite and GLM; changes in one system reflect in the other. However, there is one exception to be aware of:

When an existing CommunitySuite profile is linked to a grant through the GLM Bucket during grant processing, changes made in GLM going forward will add a new address line in CommunitySuite rather than updating the existing integrated address. This behavior is by design, to avoid overwriting data, but it means addresses can accumulate in CommunitySuite over time if left unmanaged.

This exception does not apply if you create a new CommunitySuite profile from within the GLM or SLM bucket during a sync. In that case, the address is fully integrated and updates as expected.

In all other scenarios, the address is fully integrated: updating it in CommunitySuite updates it in GLM, and vice versa.

If both a CommunitySuite profile and a GLM (or SLM) profile already exist for an organization but have not been linked, the recommended approach is to link them from Profiles > Create > Search GLM. This maintains consistent address-updating behavior and avoids accumulation over time.

The most reliable approach is proactive profile linking from CommunitySuite before syncing from GLM. This ensures the integrated address behaves as expected from the start. See Integration of Organization and User Fields for full details.

Duplicate profiles are one of the most disruptive data quality issues in a connected system. How you handle them depends on whether your databases are already linked and which profiles have sync relationships.

Before You Link: Clean House First

• Clean up duplicates in each database independently before connecting GLM, SLM, and CommunitySuite.
• Think through parent/child structure before linking; you must unlink parent/child profiles before merging in CommunitySuite.
• Plan your address strategy before linking so you do not have to undo decisions later.

Resolve Duplicates When Systems Are Already Linked

The merge process depends on how many of the duplicate profiles are currently linked.

Only one profile is linked (in GLM, SLM, or CommunitySuite):

• The linked (synced) profile must remain as the primary.
• The unlinked profile is merged away into the primary.
• This process works the same in CommunitySuite, GLM, and SLM when only one profile is linked.
• Note: CommunitySuite will prevent you from merging a linked profile away; the linked profile must always be the one that stays.

Both profiles are linked:

1. Unlink both profiles from within CommunitySuite. (There is no unlinking option in GLM or SLM; this must be done in CommunitySuite.)
2. Merge the profiles in CommunitySuite as soon as possible while they are unlinked.
3. Merge the profiles in GLM or SLM as well.
4. Re-link from within CommunitySuite to the GLM/SLM profile.

How CommunitySuite Detects Duplicates

CommunitySuite compares profiles across three dimensions: name, email, and phone. Each is evaluated independently. Matches are not flagged when:

• All profiles in a matching group have unique addresses
• Each phone number is linked to a unique email address
• Profiles share a phone but have different last names
• Profiles are already in the merge queue

Evaluate Before Merging

Some apparent duplicates are intentional, such as parent/child organizational relationships or a legal name vs. an operating name for an organization. Before merging any profiles, review the full footprint of each:

• Transactions, designations, portal access, and login credentials
• GLM, SLM, ACH, and recurring gift relationships
• If any active relationships exist, coordinate with program or finance teams before proceeding

When a duplicate is intentional, document the rationale using an Alert with a consistent Note Type (suggested: "Notice of Duplication"). Alerts are the most visible method for cross-team communication and turn institutional knowledge into institutional record.

When merging users and profiles: It is recommended to always merge from the profile without login credentials into the one that has them.

• Document everything. Written processes for address updates, profile creation, and duplicate management protect your team and ensure consistency as staff changes occur.
• Stay consistent. Select one system for address updates and follow it consistently. It is recommended to revisit that decision as your team grows, and to update written procedures when changes are made.
• Clean house first. Clean each database independently before linking GLM, SLM, and CommunitySuite. Cleaning after linking is significantly more time-consuming.
• Make data hygiene ongoing. Build duplicate reviews and address audits into regular processes so they become second nature across the whole team.