Blog
March 20, 2025
In case you missed it
Read part one, The Benefits of Blueprinting in Salesforce Implementations.
The Benefits of Blueprinting in Salesforce Implementations – Attain Partners
Now, let’s see this in a real-world scenario to help paint the picture of how this could work for your institution. Below, we’ve outlined case management for a fictional university called Empowered University.
Note: Empowered University is entirely fictional and is not based on any real institution.
Empowered University Blueprint
Build Assumptions
This document is intended for use by project managers and System Administrators with a technical understanding of Salesforce and their institution’s Salesforce org.
This guide presents the considerations and steps System Administrators should take when onboarding a new program into the Empowered University Salesforce org. The below assumes that with a program entering this Salesforce org, the program will be using at least one of the two Salesforce-supported tools:
- All users working with Cases will have a full Salesforce license.
- Not all Cases should be visible to all users.
- Each team/department using Case Management in Salesforce will provide a unique email address for Email-to-Case.
- The current architecture (e.g., EDA or NPSP, Education Cloud, Service Cloud) will serve as the basis of the org and will not be replaced within the next five years.
Decision Checklist
Staff/Support Team
- Team Structure
- What support teams exist within the larger team or department?
- What roles can individuals be grouped into? (e.g., frontline staff, advisors, TAs, deans)
- Should other teams/departments see your Cases or student inquiries?
- Do Cases need to be rerouted to a central IT team?
- What logos does the team/department use?
- Are Google Forms, paper forms, or other RFIs in use?
Case Processes
- What categories (and subcategories) of inquiries/support exist?
- Does the team or department have an FAQ or other resource bank for self-service?
- What shared email addresses are currently used?
- Required email resources:
- Default no-reply email address (Recommend standardized “[email protected])
- Email-to-Case routing email address
- Email templates (optional; if desire is to use existing automation’s templates only)
- New Case Confirmation
- Closed Case Confirmation
- Program-specific templates (as desired)
- Quick Text (optional)
- Does the team/department currently have a knowledge base or directory for FAQs?
Reminder: This decision checklist is intended to help guide or prepare for conversations during discovery, not replace a formal discovery with a department.
Build Strategy
The below sections detail Salesforce updates that would need to be considered or completed by a System Administrator.
General Security Updates
Role Hierarchy Update
- Create a new branch for the department/team.
- The highest-level user being {School} Dean, reporting to the top-level “System Administrator.”
- Define and create additional roles reporting to the {School} Dean as defined by the department.
Org-Wide Defaults
- Case: Internal: Private; External: Private
- {Department} Form: Internal: Private; External: Private
Public Groups
- Create a new public group for the department and each support team as defined by the department.
- Use public groups for sharing rules. This allows for easy adjustments as more complexity arises over time (i.e., add the Public Group “IT” to a department’s Public Group so that the IT department can see and support these cases).
- If the incoming department has a subset of students needing specific access, create a new public group for them as well: {Program} Students.
Sharing Rules
Create sharing rules on Case granting access to the Public Group and not role.
| Criteria | Shared with | Access Level | Explanation |
|---|---|---|---|
| (Case: Case Record Type EQUALS Advisee Record) AND (Case: Department EQUALS {Program}) | Role and Internal Subordinates: {School} Dean | Read/Write | Grants read/write access to the Advisee Record for all students in the program. |
| {various as required} | {new roles} | {may vary} | Grant appropriate read and/or edit access on non-advising cases to the new program roles |
Permission Sets
- Include in a new Permission Set Group for each role as needed.
- Case – Read/Edit {School} Cases: Grants read/edit access to the school or department’s record type on Case.
Case Management
Required Artifacts
- Default no-reply email address (if not using default no-reply)
- Email-to-Case routing email address
- Email templates (optional, if desire is to use existing automation’s templates only)
- New Case Confirmation
- Closed Case Confirmation
- Program-specific templates (if applicable)
- Quick Text (optional)
Case Standardizations
- Page Layouts: Default page layout style includes Feed, Post, Knowledge…
- Status field not displayed: Use standardized screen flows and conditionally displayed buttons to enforce previously defined criteria is met before updating or closing a Case.
- Hide Close Case button if the Status = New.
- Hide Reassign Case button if the Case is closed.
- Hide Reopen Case button if case is open.
- Standardized status values:
- New, Working, Pending Response, On Hold, Escalated, Closed – Abandoned, Closed – Resolved.
- Automation: The following actions occur for all support cases with no customization or exception:
- Email confirmation sent to Case Owner when a Case is created or reassigned.
- Status is updated from “New” to “Working” when an outbound email is sent.
- Status is updated from “Pending Response” to “Working” when an inbound email is received.
Global Picklist Values
- Add school/department to Support Department.
- Add department’s sub-teams to Support Teams (if any).
- Add school/department’s desired Categories to Support Categories.
- Add school/department’s Subcategories to Support Subcategories.
Queues
- Create a queue for each identified support team and department.
- Ensure that members are added based on Role.
Case Updates
- Create a new Record Type for the department/school.
- Update picklist fields (Category, Subcategory, Support Department, Support Team) picklist fields and dependencies, and which values are assigned to this new record type.
- Update the Email action on Case: Set default FROM email to be the email.
- Update Case Assignment Rules.
Global Actions
- Create a new global action for {Department} Support Case for the new Case record type.
- Set predefined values as required.
List Views
- A list view is automatically created for each new queue assigned to manage Cases—update the fields displayed in that list view as necessary.
{Department} Form
Note: This custom object should be created if the new incoming department has several specific, formulized RFIs or requests for assistance (e.g., add/drop a course, contest a grade, change assigned advisor). These may exist as paper forms or electronic forms.
- Create a new custom object when several forms (google, paper or other) are used by a department.
- Create a Master-Detail or required Lookup field to Case on this custom object.
- Do not allow activities—encourage all communications remain on related open Case.
Resources
Empowered University needs to identify and fill the following roles for implementation of Case Management for a new school or department.
- Part-time BA
- Discovery
- Support Design Presentation
- Testing
- Training Documentation Support
- Knowledge Management Setup Support
- Change Management
- System Admin (Full Time)
- Build work
- Deployments
- Documentation (System-level)
- Meetings and program correspondence
- Testing and testing preparation
- Business SMEs
- Process Questions/Support/ Remove Blockers/ Approvals
- Content for Knowledge Articles
Deployment and Regression Testing Strategy
Empowered University requires all implementations complete a thorough end-to-end user acceptance testing prior to any production changes or new users/user roles added to production. The requirements for testing are as follows.
- Testing will be completed in the FULL sandbox.
- Test scripts and results documented in a shared Google Sheet.
- A minimum of two (2) subject matter experts (SMEs) per persona complete testing.
- One (1) week minimum for User Acceptance Testing (UAT).
- Only one UAT occurs at a time within the FULL sandbox.
- All deployments to the FULL sandbox will be frozen during the UAT period.
Timelines
Timeline to onboard a new program to Empowered University Salesforce org, using case management:
The estimate includes an initial week for discovery and design so that decisions the new department needs to make can be discussed and agreed upon prior to build. These include the amount of RFIs / electronic support forms currently in use. Estimates are:
- Week 1 & Week 6: 0.5 FTE
- Weeks 2-5: FTE
The amount of time it would take to onboard a new program depends greatly on the amount of complexity involved for the requirements shared by the program. Our general recommendations are as follows.
Timeline Assumptions
The timeline below assumes 40-hour weeks that include the following tasks.
- Build work
- Deployments
- Documentation (system-level)
- Meetings and program correspondence
- Testing and testing preparation
The estimates below are recommendations based on the current automation configuration. Optimizing the automation structures and prescribing some standardizations across programs can provide a more streamlined onboarding process.
Another consideration for streamlining onboarding would be to invest in automating regression testing. Refer to the Resources, Release Management, Recommendations, and Long-Term Considerations section. Also, refer to overall blueprint assumptions.
Risks and Opportunities
The section below expands upon technical decisions that may introduce limitations or offer enhancements for future implementations.
Risks
Salesforce Limits
- Approaching limit on restriction rules on Case (5 maximum).
- 2,000 Emails from Salesforce per 24-hour period (includes automated email sends and bulk-email sends). Departments are beginning to request bulk-email messaging functionality/list email sends, which is not scalable for the number of departments planned to use Salesforce. These users are not actively using Marketing Cloud today.
Build Decisions
- Case standardizations limit department customizations, particularly on case Status. There has been continued general confusion on the definition of each status and when staff should be updating a Case’s status.
- Custom no-reply email addresses instead of the default no-reply email has forced custom Flows when default Support Settings can provide similar functionality.
Other
- The implementation team receives a large number of support questions from staff within the first month of implementation. This is time-consuming support work and often relates more to business processes than technical issues or bugs.
Opportunities
- Knowledge can be implemented and expanded to support Case management.
- Cases can be displayed to students within a portal if Experience Cloud is implemented. This would address concerns about student visibility to the status of their cases.
- Recent departments have requested an event management tool that can tie cases to specific events. Explore Salesforce-based event management systems.
Recommendations
The following recommendations could benefit the Empowered University Salesforce org’s health, maintenance, and/or end-user experience:
Delegated Administrators
- Offloads user management tasks to school-level admins
- Opens more time for System Admins to focus on support and enhancements
Data Storage and Retention Policy Establishments
- Establish retention policies to avoid hitting data or file storage limits
- Review storage of Marketing Cloud emails and other data consuming significant storage space
Release Management
- Create a release management strategy that includes regularly scheduled refreshes of sandboxes. This could include the following:
- Deployment Structure: (Project-specific Dev orgs) → DevPro or Partial sandbox for initial QA and regression testing → FULL sandbox for full regression testing.
- Refresh QA and FULL at least three times per year, ideally after Salesforce’s tri-annual releases are made in Production.
- Promote a development “freeze” in FULL during full regression testing (and in QA on an as-needed basis).
Attain Partners – Salesforce Experts
No matter if your organization is beginning its Salesforce journey or 10+ years into development, Attain Partners is here to help you achieve your goals. Contact our team today to learn how we can help your organization advance its mission by harnessing the power of Salesforce.
To learn more, check out our Salesforce Innovation services, read case studies about our transformative work, and explore blog posts from our Salesforce experts.
About the Author
Jamie Sohngen is a Senior Consultant at Attain Partners. She brings 7+ years of professional experience across multiple industries including higher education, K-12, nonprofit, and for-profit sectors. Jamie has implemented several Salesforce products such as Student Success Hub (SSH), Outbound Funds Module (OFM), Program Management Module (PMM), Education Cloud, NPSP, and EDA in addition to designing custom architecture solutions.
