One of the common needs, or at least desires, for CRM users is to link their CRM to some kind of constituent portal. There are several ways your can architect a good data pattern for your constituent portal. The trick is picking the right one for your organization.
This is the first in a series on what your choices are, and now to select the right one. The architecture you select will drive the implementation cost, maintenance costs, and scalability.
The Purpose of Your Constituent Portal
Before deciding on the architecture of your portal, you need to have a clear understanding of its intended purpose and expected scale. The purpose of the portal will also dictate the direction(s) data flows, and the scale will help you plan the long term costs.
If you can’t clearly state why you need a constituent portal, you don’t need one.
Different organizations have different reasons to create portals. Companies that sell products may want a warranty or support portal. Nonprofits often want a donor portal that provides tax recipes and allowed recurring donors to update their gift information. Member organizations want a place for members to see their benefits, update their information, and renew their memberships. And so on.
The purpose of your portal will determine the direction that data flows through it. There are essentially three directions that data can move.
Outbound Data
You can send data from your organization to your constituent. That could be things like receipts, memberships status, or product warranty information. Anything that is data you have, that your member might need to see, but not update.
Data Exchange
You can allow constituents to update information. That could be address changes, support requests, donation schedule updates, event registration details, and more.
Data Network
Your third option is to allow you constituents to exchange information with each other. This could be a any form of member community where they engage with each other.
When planning a network, remember you have to plan for content moderation and acceptable use policies.
Primary Portal Data Architectures
To support your portal, whatever the data flow is, there are three main data architectures you can choose from, each which a different strengths and weaknesses. The more complex your architecture the more options you will have for what it can support, but it will also increase costs and maintenance efforts. Bigger is not always better – sometimes it’s just more expensive.
1. All-in-One Constituent Portals
In an all-in-one solution your constituent portal is part of your CRM. For obvious reasons this is the type of portal that your CRM vendor wants to sell you. In Salesforce land this means Experience Cloud. There are also many nonprofit-focused CRMs which include one in their solution. When your portal is part of your CRM you get a bunch of advantages:
- Data all lives in one place. There is no data sync to worry about setting up or maintaining.
- You have one vendor. That means you can centralize your support arrangement and billing.
- They are often fastest to implement. They are designed to be fast to market to help make them the obvious choice.
- They generally do not require a developer. Again, your CRM vendor really wants you to select this path, so they clear as many hurdles as they can.
- There is only one technology stack. By leveraging the technology of your CRM your investments in learning that technology carry over, at least in part, to your portal.
There are also downsides:
- New template system to learn. The CRM’s portal likely has a different template system than the CMS on your main web site. That may be hard to make match your primary online branding.
- The vendors make a lot of assumptions. To provide that ease listed above they make assumptions about how data flows, security, user experience, and how other elements should work – those assumptions may not match your ideal solution.
- Costs often scale linearly. There are usually license costs that are scaled based on user count meaning your costs grow as the portal grows at more or less a 1:1 rate. While there are price breaks and other incentives this is the right expectation to have for estimating.
2. External Constituent Portal
In this pattern an external constituent portal moves the user experience from within your main CRM’s sphere of influence into a separate platform. In my career I’ve mostly built these with Salesforce as the CRM and Drupal as the portal platform – it’s a powerful pairing. The strengths and weaknesses here are more or less the mirror of the all-in-one portal.
- You web team may already know the technology. If you use the same technology as your web developers use for your main web site(s) they already know who to handle design and branding.
- You have greater control over the User Experience. The assumptions that go into the portal are yours not the ones imposed by the CRM.
- You have greater control over security, along with data flow and formats. Since they aren’t built around assumptions you don’t control you have greater control and freedom.
- Costs typically grow more slowly. It is less common to have per-user license costs in this context so the cost curve is likely closer to logarithmic.
The downsides:
- You have to handle data synchronization. The two systems means data has to pass back and forth.
- You have two difference vendors/platforms. When you had one system everything was centralized, now you have two different systems handling constituent data.
- This design typically is harder to implement. All those short cuts your CRM provider had in mind for you are gone. Even if you use purpose built solution it’s going to take more time and effort.
- This approach generally requires a developer and/or data architect. To implement this pattern you need someone who understands both platforms – ideally both for setup and support.
3. External Constituent Portals with Data Proxy
In some situations it makes sense to insert a data proxy, or API layer, between your main CRM and your constituent portal. This creates a layer of abstraction, security, and data augmentation that can benefit a lot of organizations. While this is the most complex of the three main architectures it is one I find is frequently overlooked – in part, I suspect, because no one partner benefits from selling it.
This setup certainly isn’t for everyone, but when it’s the right fit it makes a huge difference. It also creates a significant number of iterations – all of those arrows could be one directional or two directional.
An extra data layer makes the most sense when data from your CRM is going to multiple places and/or needs to be augmented by an external data source. For example think about an organization that provides trail maps for hiking or paddling. All that data about trails does not need to be in your CRM, but you probably want to know which members are interested in which trails. An organization like that may have a portal for members, a web site to find trails for non-members, apps for iPhone and Android, and perhaps a public API for other people to use to build their own web sites with. That’s a lot of API calls all with different data sets, all of which need to be very fast.
Your CRM is designed to be very stable and reliable – it is not designed to be very fast. What’s more, you often have limits on the number of API calls you get in your package with extra fees charged if you go over. By inserting another layer between your CRM and other needs you can bypass these limitations.
There is another added benefit to this design pattern, and that is increased security. By creating an additional layer in your system you are able to create a separation of concerns between the various systems. Each should have access to only the data is absolutely needs from any of the others.
How to Pick?
There are lots of considerations that go into selecting the right architecture for your project – which is why that’s getting it’s own post soon.