Blog
February 24, 2025
As Salesforce orgs mature at an institute or university, the teams supporting these orgs find themselves faced with difficult challenges and limited time and resources. Challenges we at Attain have seen with our clients include:
- Moving to a new org or data architecture, such as an EDA migration to Education Cloud
- Large amounts of technical debt, hanging on by a handful of custom fields or idly waiting for the opportunity to be purged
- Unwieldly automation and infringing API limits
- Redundant fields and data, or disconnected data limiting report functionality
- Time dedicated to bug fixes and org maintenance overshadowing ongoing innovation and growth
When assessed, the causes of these issues often stem back to decisions made months or years ago that are now seemingly impossible to untangle. For the teams who face migrating an org in this state to a new Salesforce instance or architecture—or for the teams just starting out—blueprinting can provide a helpful guardrail to repeating this vicious cycle.
In the below article, we address how to implement blueprints and the benefits they provide.
What is Blueprinting?
Blueprinting involves future-framing a project implementation to ensure both designs and team resources can scale with your organization’s future roadmap. Creating a blueprint alongside an implementation takes a strategy-forward approach to build, encouraging developers to consider “How else will this be used?” while providing transparency to project managers and leadership on potential risks and opportunities for quick wins.
A blueprint typically exists as a document or series of connected resources in a system like Confluence or Quip Notes (Note: These resources must be connected). This document contains a combination of technical and non-technical language which addresses design decisions and their repercussions.
What is all this for?
What benefits does the practice of blueprinting provide? For those of us staring deep into the pits of a complicated Salesforce org with abandoned customizations and heaps of technical debt, the benefits may seem endless. For others still apprehensive, consider the following:
Solutions become more scalable
- Avoid unused fields and objects
- Decrease onboarding time for the next programs
- Defined security model
- Clean, concise automation strategy
Considerations for future risks
- Avoid unused fields and objects
- Decrease onboarding time for the next programs
- Defined security model
- Clean, concise automation strategy
Governance and Maintenance
- Data retention policies
- When and what to integrate
- Delegated Admins
- Release Management strategies
Future State-of-the-State Framing
- Define systems working with Salesforce or to be replaced
- Prioritize based on estimated timelines and available resources
What to Include in a Blueprint
The following lists the recommended sections to include within a blueprint.
Build Assumptions
All teams begin build with what they believe the best solution is based on known information at the time. However, as any team has experienced, realities and the requirements they demand change. Identifying assumptions as part of a blueprint allows everyone to agree on a basic starting point from which more granular nuances may still be managed.
Decision Checklist
This section of a blueprint is intended for use by a project manager in coordination with new staff who will be onboarding to Salesforce. This helps equip project managers and build teams with the required information they need to start a new build.
Note: The decision checklist is not intended to replace a formal discovery with a department. Rather, this helps guide or prepare for conversations that would arise during a discovery.
Build Strategy
The build strategy defines explicitly technical decisions made in response to decision checklist responses and assumptions documented. These should be documented by functional nature ideally, such as defining a sub-section for “Security” where org-wide defaults, sharing rule reasoning, Public Groups, Roles, and Permission Sets are defined in a scalable manner.
Resources
This defines the people resources it took to implement a project and estimates what would be required to expand it to another team or future enhancement phase. This provides the technical team the opportunity to share effort estimates and recommendations for the distribution of work between team members. When delegated administrators or other roles outside of the technical team are involved, this is a great way to set expectations for what will be required.
Deployment and Regression Testing Strategy
Scaling any solution involves regression testing. Planning ahead for regression testing—designated testing sandboxes, timeline implications, and testers—is crucial to success in any deployment. Identifying areas that will require regression testing during the initial build period helps to gather regression testing scripts when it is fresh in the mind of the build team.
Testing is a big part of any project implementation we do at Attain Partners and should be included in your blueprint as well.
Timelines
Identifying a timeline for scaling a product is not a set-in-stone process, but does provide for a helpful planning model. When there are significant unknowns when scaling, it is prudent to consider various time estimates and to document technical limitations that would impact these.
Risks and Opportunities
This section expands upon technical decisions that may either cause limitations or offer enhancements for future implementations. For example:
| Risk Area | Considerations (Examples) |
| Salesforce Limits | Have you created a significant number of custom fields on a standard object? Check approaching custom field limits. Significant number of sharing rules on an object? Be aware of criteria-based sharing rule limits in Salesforce. Using Restriction Rules? Consider functional limits and scalability, including no more than 5 are permitted per object. |
| Build Decisions | Are custom flows driving business processes? Consider if those business processes will be adopted by future teams who will also use Salesforce. Are third-party tools installed and license-driven? Consider the time and/or cost for increasing licenses. |
| Opportunity Area | Considerations (Examples) |
| Sunset Systems and Streamline | Have third-party packages been installed that can replace other existing systems? Does the implemented solution replace an existing process within Salesforce? Identify chances to remove technical debt if the current implementation (or timeline) did not account for replacing or removing unnecessary customizations. |
| Implementation Process | What went well? What can be more easily expanded upon than others? |
| Future Phase Enhancements | What feature enhancements were requested or could be recommended for a future phase? |
Recommendations
Often when a solution is implemented, ideas come up that don’t quite make it to go-live. Documenting recommendations here allows for these ideas to not get lost in the fray (i.e., the immediacy of go-live support or the constant attention you’ll be receiving after your implementation).
These may or may not be technical in nature. For example, a recommendation could be implementing a data retention policy, identifying “super users,” or creating opportunities for end users to submit a survey or share their feedback three to six months after their go-live.
If your technical team is using a tool such as Jira, Apsona, or something else for task management, ensure these recommendations are tracked in a place that is visible to not just the technical team, but also easily accessible to other stakeholders.
Attain Partners – Salesforce Experts
Regardless of where your organization is in its Salesforce journey (or if it’s yet to start!), Attain Partners is here to help you achieve your goals and serve your community. 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.
