If you’re thinking about consolidating databases—moving an operation from multiple, dedicated databases to just one—it’s worth considering the pros and cons.

Here, we lay out the benefits and drawbacks of sharing databases among lifecycles (Admissions, Student Success, and Advancement) or other administrative units.

Data utilization

In a shared database

Valuable information collected in Slate, such as extracurricular interests and communication preferences, can be used by various departments to make informed decisions and customize engagement strategies.

Across multiple databases

Data is specific to each database (e.g., graduate or undergraduate), allowing focused utilization within that department without the need for broader collaboration.

Record separation

In a shared database

Records can be managed by adding statuses like "enrolled" or "alumni" to the existing statuses (e.g., "prospect," "applicant"), ensuring they are included in relevant business processes.

Across multiple databases

Records are maintained separately within each specific database (e.g., graduate), simplifying record management tailored to that department’s needs.

Permissions

In a shared database

Permissions should be set early in the process to control user, object, and record access across departments, ensuring that privacy and data sharing are appropriately managed.

Across multiple databases

Permissions are confined to the specific database (e.g., graduate), allowing for straightforward management without cross-departmental concerns.

Institutional culture and communication

In a shared database

Consideration of how well departments such as admissions and student success work together is important. Regular communication and trust are key when sharing data across departments.

Across multiple databases

Departments operate independently within their specific databases, allowing each to maintain its own culture and communication practices.

Branding and URL

In a shared database
The database’s branding and URL may need to be updated to reflect broader use beyond a single department, potentially involving collaboration with the marketing team.

Across multiple databases
Each specific database (e.g., graduate) maintains its own branding and URL, designed for that particular focus area without needing to adjust for others.

Data integration

In a shared database
Sharing a database may involve integrating data from various systems (e.g., SIS, LMS) across departments, ensuring that relevant data points are accessible where needed.

Across multiple databases
Data integration is handled within the specific database (e.g., graduate), tailored to that department’s systems and workflows.

Profile tabs

In a shared database
The Profile tab can store and display multiple data points, useful for various departments, but strategies may be needed to distinguish between data types, especially when combining legacy information.

Across multiple databases
Profile tabs are customized for specific database use (e.g., graduate), focusing on the unique data points relevant to that department.

Default email address

In a shared database
A default "Reply To" email address, such as [email protected] or [email protected], can be agreed upon for all communications within the shared database.

Across multiple databases
Each specific database (e.g., graduate) sets its own default email address, maintaining control over its communication channels.

Folder naming convention

In a shared database
Folder naming conventions should be reviewed to ensure they work effectively for all teams within the shared database, possibly using identifiers like ADM or SSA.

Across multiple databases
Each specific database (e.g., graduate) maintains its own folder naming conventions, making organization straightforward and specific to that focus area.

Payments

In a shared database
If payment processing is involved, it may be beneficial to consolidate to one provider, though multiple providers can be configured if necessary.

Across multiple databases
Each specific database (e.g., graduate) selects payment services independently, focusing on its unique payment processing requirements.

New features

In a shared database
Communication about new feature releases is crucial to ensure all departments are aware of upcoming changes and can prepare accordingly.

Across multiple databases
Feature releases are managed within each specific database (e.g., graduate), allowing for focused implementation without needing cross-departmental coordination.

Timeline tab visibility

In a shared database
The Timeline tab provides a comprehensive history of interactions, visible to all users with access. Managing access can ensure privacy while allowing necessary visibility across departments.

Across multiple databases
Timeline data exists within the specific database (e.g., graduate), relevant to users within that department, without the need for managing access.

Person status rules

In a shared database
Additional person statuses, such as "Matriculated" or "Alumni," can be added to help track different stages across departments, requiring rules to manage these statuses.

Across multiple databases
Person statuses are managed within the specific database (e.g., graduate), with rules tailored to that department’s workflows.

Automations, queries, and reports

In a shared database
Established rules, queries, and reports may need to be reviewed to ensure they function correctly across all departments in the shared database, avoiding cross-departmental conflicts.

Across multiple databases
Automations, queries, and reports are tailored to meet the specific needs of each database (e.g., graduate), simplifying management.

Authentication and Single Sign-On

In a shared database
You can configure different authentication methods, including SSO, for various stages (e.g., applicants vs. matriculated students) within the shared database.

Across multiple databases
Authentication methods are managed independently by each specific database (e.g., graduate), allowing for customization based on that department’s needs.

Support Desk

In a shared database
Designate "Captains" across departments to handle support tickets and ensure efficient resolution of issues within the shared database.

Across multiple databases
Each specific database (e.g., graduate) designates its own "Captains" to manage support tickets, focusing on their specific needs and issues.