Category Archive: Implementations

Make A Good First Impression With Your Homepage

According to Tony Haile (CEO of Chartbeat), you have about 15 seconds to capture a person’s attention before they lose interest and leave your website. In order to do that, it is important to efficiently demonstrate what value you provide to your customers, without providing too much content and potentially overwhelming visitors. In order to strike that balance effectively, it is best practice to provide a small amount of information (a sentence or two) in each value proposition with a call to action prompting the user to learn more. For example, this call to action might be in the form of a “Learn More” or “Register” button. This quickly demonstrates how to access valuable information promptly, without users having to sift through a large volume of content first. Providing too much information up front can not only be overwhelming, it also provides no incentive for people to explore the rest of your site.

NetForum Enterprise is a feature-rich association management system (AMS), but most associations will inevitably find themselves needing to customize. That’s fine – NetForum allows customizations. The challenge comes in down the road when you’re looking to upgrade and the customization does not support new functionality available in the new release or worse breaks down completely. Implementing customizations that leverage baseline may reduce your heartburn during future upgrades enhancements. Here are a few customization trade-offs to consider.

User Control vs Design Form with Form Extension

Capturing data in NetForum is critical, and forms are key to any data entry. To create the most simplified NetForum eWeb customer experience, you may need to customize your form’s format and fields. A coded user control overrides default form builder limitations and allows for maximum control. But, everything is written in code, so adding an additional field to the form is not a drag and drop situation. Someone will have to dig into the code.

Alternatively, consider using a design form with a form extension. This allows for a portion of the form to get customized within the form extension, but still have the flexibility to add fields using the Toolkit form designer. If you later decide to add an additional column to the form, simply drag and drop and you’re done!

Baseline Scheduled Task Framework

If you’re building out any customizations that either update data within NetForum or push data out to a third-party system, building out a scheduled task may be needed. This is completely normal. The problem arises when the scheduled task is not built within NetForum’s baseline scheduled task framework. Within the scheduled task framework, any Admin user can go into the admin module and review existing tasks, see when it last ran, and see how often it will run going forward. While not working within the framework may be fine for now, it is likely to cause future problems. Building the task in the baseline framework would allow you and your staff to better troubleshoot the scheduled task should problems arise. Think of it as process documentation: you don’t need to spend the extra effort upfront for the system to work, but three years from now you’ll thank yourself that you did.

Facade Objects to Enforce Business Rules vs Form Extensions/Data Objects/Direct SQL

NetForum provides a layer of facade objects where business rules can be enforced, allowing for a great deal of control and customization. The challenge is the rules around those objects is more specific to NetForum. It may be tempting to simply build logic directly into the SQL database. However, the SQL may not follow other business logic stored in the facade object. In fact, it may directly contradict baseline’s or other custom business logic. Implementing a business rule in Form Extensions causes a similar issue in that the business rule is only enforced on that particular Form. When a second form is used, or the functionality is exposed through the API (xWeb), the rule is ignored. So While direct SQL and Form Extensions can work for basic items, updating the facade object and, following OOP’s inheritance best practices is generally a better approach in the long run.

Static ASPX page vs. baseline ASPX page

As more associations look to better leverage eWeb, there are increasing requests to customize the site. The current baseline eWeb does come with its limitations – forms only have a single column, baseline menu isn’t truly responsive (although this can be fixed). However, the eWeb baseline feature set has continued to grow over time. While building a static ASPX page feels like an easy improvement to eWeb, you may be sacrificing the ability to leverage future functionality at the expense of current convenience. New features that get added to NetForum won’t be available on the static page. Instead, try to leverage the baseline page, along with other customization tools, knowing it will provide more longevity for the site.

“Leveraging” bugs

This sounds strange, but over the years I have seen a few occasions where customizations or “cool tricks” were implemented that leverage either existing “bugs” in NetForum or perhaps an unknown vulnerability. At the moment, the customization works and delivers the functionality your organization needs. Inevitably, after the issue is fixed in a service pack or a new release, these customizations stop working. It might be alright to leverage “unintended features” as a stopgap, but be prepared to re-implement the customization sooner rather than later.

Unfortunately, it’s not always easy to distinguish an “unintended feature” from an unknown system issue – so perhaps the best advice here is to ask “Does this look right?” or “Would there be a reason for this variable to have a different value in a future release?” – when in doubt avoid it.

For many associations, the best fit would be the Supportive model, which is what we have adopted at fusionSpan. It is the easiest to implement and there should be fewer challenges associated with buy-in. A Supportive PMO can be especially beneficial for associations that frequently need to share resources, as it allows for standardization and additional resources to ease stress on busy staff.

While working at fusionSpan, I have been part of the Salesforce team’s effort to set up and maintain a Supportive PMO internally. Despite it just being implemented, it is evident that having a one-stop-shop for things like standardized templates, processes, etc. has had a positive impact on our team’s efficiency and project delivery. For more information on PMO best practices and project management generally, I strongly recommend visiting the Project Management Institute’s website (pmi.org).

1. Project Management Institute. (2017). A guide to the project management body of knowledge (PMBOK guide). Newtown Square, Pa: Project Management Institute.
2. “The High Cost Of Low Performance.” PMI’s Pulse Of The Profession, www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2016.pdf.

One of the biggest challenges with association management system (AMS) implementations is that organizations often confuse processes in their old system with their business requirements. When this happens, organizations request customizations to make the new system function like the old system. [Read one of our related blog posts: Enterprise AMS: When is a customization right for you?] Wasn’t the original goal of selecting and implementing a new AMS to improve—not maintain—your business processes?

Understandably, it’s hard for people to separate what they do (process in the current system) vs. why they do it (business requirements), and that’s generally not something a vendor is going to be able to separate out for clients. It’s the difference between accounting claiming they need a report with 12 specific columns run every month (process in the current system), vs. knowing that the reason they need that report is to follow up on open A/R once a month (business requirements). If the client doesn’t explain the why and instead focuses on the what, the vendor will likely build a report when an automation process may be more efficient.

Business Process Discovery Planning

This all leads into a business process discovery prior to implementing a new system. This makes a lot of sense, since a business process discovery can also help define what you will need in a new system. But how do you prevent the business process discovery from becoming current system processes? Staff will struggle to separate the two.

One more costly option is hire a consultant, who can offer a fresh perspective during your business process discovery. Alternatively, if money is an issue, consider replacing a consultant with other staff.  Staff, if strategically selected from across your organization, may be able to bring a similar fresh perspective, if they are far enough removed from the day-to-day of other departments.

Business Process Discovery Steps

Now you have a discovery team identified, have them go through the following steps:

1. Have staff identify all the current system processes they complete that require the AMS.
2. Explain the business process that each system process supports. Business processes should be described in such a manner that anyone can understand them. Note that in some cases, multiple steps may relate to the same business process. Generating renewals and dropping expired members could both be related to 12-month membership terms.
3. Once finished, trade off their document with at least two people from other departments to review.
4. The reviewers are responsible for ensuring the business requirements are clear. If the business requirements are not instantly understandable by the reviewer, then the requirements will need to be further clarified. For instance, the reason all memberships are issued as proforma is because the organization uses cash-based accounting.
5. Go through a couple rounds of edits until everyone is satisfied that the business requirements are no longer reliant on the current system.

Post-discovery

Once the business requirements are solidified, that document should serve as the foundation for all future decisions. When reviewing new potential AMS systems, ensure that all the business processes are supported. Once implementation begins, ensure processes in the new system are identified to support the business process. Staff should ensure they focus on business processes, and because the business process document was a collaborative effort, staff should feel comfortable calling out when they hear someone describing the old system processes instead of business processes. Granted, there are cases where the old process and new process will be very similar, but as long as the business process was the catalyst for the new system process, that’s not a bad thing.

Conclusion

While a business process discovery can be a time consuming exercise, the activity is far less painful than implementing a new AMS that does not accommodate an organization’s business processes. Additionally, by having staff from across the organization collaborating on processes, departments can better understand how their actions in the AMS impact others. Ideally, that collaborative spirit will carry on well beyond the AMS implementation, ensuring the long-term success of the system.

Conclusion

SSO synchronization is more often than not an afterthought of SSO implementations. There are other methods to accomplish SSO synchronization between multiple websites, including those that are on different domains, however if your websites share the same Top-Level-Domain, then an SSO Domain Cookie approach is a simple and a fairly straightforward method to implement.

Imagine you work at ABC company, who owns and manages 3 websites:

1. An Identity Provider website: AMS.abc.org, and
2. Two satellite “Service Provider” websites: CMS.abc.org and LMS.abc.org.

Your customers can access courses and the community through the LMS and CMS websites respectively, and the AMS website is the system of record in which the user accounts are managed.

If you have the good fortune of having all of your organization’s websites on the same Top-Level-Domain (TLD) as in this case, “abc.org”, then a Domain cookie approach for a seamless SSO user experience might be a good option. Let’s examine how this works.

How it works:

AMS.abc.org is the Identity Provider. In other words, it is the system of record in which user accounts are managed, and it is therefore the website that will either serve the Login page, or will provide an API to be consumed by the other websites in order to authenticate users – note the latter assumes that the service provider websites are under our control and are trusted to pass-through the username/password. For our example, we will use the former.

Once a user successfully authenticates against AMS.abc.org, an authentication Token is issued and stored on the server – in some type of a database. A domain cookie (SSO cookie) is also created which contains aToken. The Token is temporary, unique, and very difficult to guess. A GUID works nicely. After this the user is redirected to the intended page. The intended page can be inferred from the URL referrer or can be specified in a URL parameter which is passed along with the URL when the user is sent to the Login page.

Because the websites share the same TLD and the SSO cookie is flagged as a domain cookie, the browser will send the SSO cookie along with any browser request to any of the websites on the same TLD – in our example, this includes LMS.abc.org and CMS.abc.org (both end in abc.org). When a request is made to a any of these Service Provider websites, the website inspects the SSO cookie, and takes the following actions:

1. If the SSO cookie exists, the Token is extracted from the SSO cookie, and is validated against the AMS API – The validation can take the form of an authenticated web service call (SOAP or REST).
2. If the Token is valid, the user is logged into the Service Provider website, and any additional user information authorized by the AMS to the Service Provider can be also requested from the AMS’s API.
3. If the SSO cookie does not exist, or the Token is not valid or has expired, the user is redirected to the AMS.abc.org Login page.

Below is a diagram that illustrates the flow:

There are two mechanisms in place now that can help keep our sessions in Sync:

1. When the user logs out from any of the websites, she/he is redirected to a logout page on the AMS.abc.org website. This page invalidates the Token and deletes the SSO cookie. Then the user is redirected to the website from where she/he logged out. Since the SSO cookie is no longer available and/or the Token is no longer valid, the Service Provider will know to “clear” the current user session, and redirect the user to either the login page or another landing page.
2. Synchronizing Login timeouts is accomplished by setting a timeout on the SSO cookie, and keeping the Login session alive is accomplished by sliding the SSO cookie and Token by “tickling” the AMS website- this can take the form of an HTTP Handler on the AMS website that is referenced by every page on the Service Provider websites.

In-Process sessions can expire at any time on any of the websites – they do not have to necessarily be in sync. The user may still be “logged in” on LMS.abc.org even if the SSO cookie and Token are expired or deleted; for this reason LMS.abc.org MUST inspect the SSO cookie and validate the Token on every request. On the flip side, if the LMS.abc.org “session” expires due to idle time, the SSO cookie and Token can be inspected and validated when the user requests the next page which would automatically log the user back in and start up a new session.

We just released a follow-up to this post!  Continue to Part 2 for technical considerations for an SSO domain cookie implementation.

If you have not already, click here to sign up to receive notifications on all fusionSpan blog posts.

Organizations choosing enterprise-level Association Management Systems (AMS) likely do so for a range of reasons. They know they’re getting a product with a rich feature set and all kinds of configuration options. They know they’ll have a greater deal of flexibility. But, likely most important, is the system can be customized to their need.

Unfortunately, customizations are a double-edged sword. On one hand, they allow the organization to completely mold the AMS to their business needs. On the flip side, customizations require extra maintenance, which is work. With that in mind, here are a few items to consider when considering a customization.

Make sure it’s a business need

When staff says, “We need the system to X because that’s how we’ve always done it.”  SIRENS should start going off. Often old processes are built around an old AMS, and if you really liked your old system, WHY DID YOU GET A DIFFERENT AMS?!? Customization should always be driven by either a business rule or business need. Business rules are usually listed in the by-laws of the organization, and business needs are a feature that will help deliver against the business goals of the organization. Requiring staff to draft up a business case for new customizations is not excessive. If nothing else, staff willing to put in the effort to come up with a business case obviously have a little conviction behind their customization request, while the folks who think it’s too much work will likely figure out how to fit their processes within the baseline.

Clearly define purpose

As part of a business case, there should be an understanding of “WHY?” a customization is needed. Too often customizations focus on how they will work, with no conversation about “why.” Having a “why” clearly defined helps ensure the effort always matches up with the purpose. If you just focus on the how, you can end up 100 hours into a development project before you know it, and if the customization only helps one person save 8 hours once a year, you’ve made a mistake. Even if you do need the customization, there will inevitably be opportunities for scope creep. With a defined purpose any scope creep items you can ask, “Does this help address why we need this customization?” If the answer is no, then keep it out of scope.

Build for flexibility

Most customizations are built to fix an issue now. Which is good — until you’re no longer in the now.  In time, you will find yourself painted into a corner.

As part of the design process, try to identify input values. These could be inputs into formulas, text descriptions, drop down fields, or any other number of values. With each of those inputs, make sure the values are captured in an area that is easy to update without having a developer get involved, either in a control panel, system option, or some other feature that can be edited, instead of having the input value hard-coded into the customization.

Think of a spreadsheet, where you have to multiply a bunch of values by 20%. For each of those fields you could go in and type 20% into each field, but then if your boss comes back and says, “Actually, we need to do 25%,” you’re now stuck finding and replacing each 20% in your spreadsheet. Instead, what you want is to type 20% into one field, then everywhere in your spreadsheet where you multiply by 20%, just reference that field. That way when you need to switch to 25%, you only have to make one change.

Granted, building for flexibility usually requires a little extra work, so balancing the right amount of flexibility against your budget is a per-project judgment, but some are always better than none.

Conclusion

While everyone wants a perfect system out of the box, most enterprise level associations will inevitably need to customize. Being strategic, purposeful and flexible with those customizations will serve you well in the long-term success of your organization’s AMS.