Category Archive: Implementations

Sales Tax Nexus: What Is It and Why Is It Important?

Himali Shah July 10th, 2023 by

Sales tax compliance is a crucial aspect of any organization that sells taxable goods or services. Staying compliant can be challenging, especially considering the ever-changing regulations and complex calculations involved. In addition to complying with state and local tax laws, associations must also consider the sales tax nexus. This is where sales tax automation tools like Avalara can make a significant difference.”

What is Sales Tax Nexus?

Sales tax nexus refers to the connection between an organization and a state that requires the business to collect and remit sales tax on taxable sales. An organization must have sales tax nexus in a state to be obligated to collect and remit sales tax. Nexus can be established through various activities, including having a physical presence in a state, selling a certain amount in a state, or engaging in other activities that create a connection between the organization and the state.

Why is Sales Tax Nexus Important?

Failing to comply with sales tax nexus regulations can have severe consequences for organizations, like penalties, fines, and even legal action. It is essential to understand the rules for establishing nexus in each state where an organization operates and to comply with the requirements for collecting and remitting sales tax.

Sales Tax Automation Tools and Sales Tax Nexus

Sales tax automation tools like Avalara can help businesses stay compliant with sales tax nexus regulations. These tools automate the sales tax calculation process, making it easy for businesses to accurately calculate and collect sales tax from customers. They also simplify the process of remitting sales tax to the appropriate tax authority.

Avalara offers a range of features to help businesses stay compliant with sales tax nexus regulations, including real-time tax rate calculations, tax exemption management, and tax reporting and filing. These tools integrate with various accounting and e-commerce platforms, which makes it easy for businesses to implement.

Sales Tax Nexus and Multi-State Operations

If an organization operates in multiple states, it is crucial to understand the rules for establishing sales tax nexus in each of those states. Each state has its own rules for establishing nexus, and it is essential to comply with each state’s specific rules to avoid penalties and fines.

Sales tax automation tools like Avalara can help businesses manage sales tax nexus in multiple states. These tools can automatically calculate the appropriate tax rate based on the rules for each state, simplifying the process of collecting and remitting sales tax.

Incorporating Avalara with your Fonteva Org

Avalara Avatax can be integrated to add tax components to the orders placed in the Fonteva store. When a product is added to the cart, the tax rates will automatically be retrieved based on the product configuration, and state of delivery of goods/services, and used in tax calculations. The integration will also write back the invoice details to Avalara so that any tax filings can be done directly through Avalara.

Leveraging Baseline NetForum Enterprise in Customizations

Hans_Stechl fusionSpan Team January 14th, 2021 by

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.

New call-to-action

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.


If you have NetForum Enterprise, you should look to customize where necessary. Part of the value of the system is the ability to customize. But make sure to consider your best options for long-term success and not just your immediate need, otherwise can end up causing more problems than you solve.

Whether you want to integrate or enhance and customize your current NetForum Enterprise system, fusionSpan is here to help.

New call-to-action

How Associations Can Leverage A Project Management Office

Avatar photo August 6th, 2020 by

While the general concept of project management is undoubtedly utilized by associations for key initiatives like events and membership management, many associations can augment their various teams’ efficiency and program effectiveness by establishing a Project Management Office (PMO).

For anyone unfamiliar with this term, a PMO is defined as “an organizational structure that standardizes the project-related [and/or program-related] governance processes and facilitates the sharing of resources, methodologies, tools and techniques.” (Project Management Institute, 2017, p. 48).1

Types Of PMOs

At first glance, this is a pretty loaded definition. But stick with me, because Figure 1 shows how there are different types of PMOs that can be implemented. In addition, each association can tailor the PMO structure to align with organizational culture, current level of project management maturity, and strategic requirements.

Figure 1: PMO Types and Definitions

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.

PMO Type Extent of Influence & Control
Supportive *PMO type utilized at fusionSpan This type of PMO primarily provides consulting. Below are some examples of resources to provide direction to staff, access to important information and tools, & prevent having to always “reinvent the wheel”:

  • Best practices
  • Training and professional development for staff
  • Templates for frequently needed documents (e.g., project plan, issue trackers, onsite event registration forms, surveys for members, etc.) Note: PMOs can add to the template repositories and manage revisions to templates on as needed basis.
  • Repositories for standardized business processes/standard operating procedures, lessons learned from previous projects, etc.
Controlling This type of PMO supports the organization similar to a Supportive PMO, but there is a required compliance component. For example:

  • Adherence to particular project management frameworks
  • Required use of particular templates, methods, tools, etc.
Directive This type of PMO entails the highest level of control, where the PMO directly manages projects. Project managers are responsible for reporting project status to the PMO.

Organizations that align their Enterprise-wide PMO to strategy report 27 percent more projects completed successfully and 42 percent fewer projects with scope creep. (PMI)2

Additionally, associations that host large scale events can leverage PMO tools and resources to improve project delivery. Regardless of the type of PMO that is selected, a required element is strong support from an association’s leadership to encourage buy-in and successful adoption.

Implementing A PMO

In planning to implement a PMO, it is important to develop a road map or game plan for what your association wants to achieve via the PMO. Association leadership should collaborate to define the PMO’s goals, and also contemplate the following questions to determine how to structure the PMO (while also delivering value to your organization):

  • What are the pain points or challenges we face in project execution? How have those issues impacted our association’s performance?
  • Do the PMO goals align with our association’s mission and strategic objectives?
  • How can we achieve our goals given our current resources and their corresponding skill sets?

Associations can even take it a step further and establish metrics to gauge PMO performance and value add. These performance measures will largely vary across association, but could include:

  • Number of projects or programs supported by the PMO
  • Number of templates/tools available
  • Number of staff with [x] certification

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 (

  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,

AMS Implementation: Why a Business Process Discovery is Essential BEFORE Making a Move

justin fusionSpan Team November 2nd, 2018 by

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.


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.


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.

Synchronizing Single Sign-On (SSO) with a Domain Cookie, Part 2: Technical Considerations

Hans_Stechl fusionSpan Team July 25th, 2018 by

In the previous post, we went through an overview of SSO with a domain cookie. In this post, we’ll dig into some of the technical considerations when implementing this SSO solution.

System Overview

As an overview, here are the responsibilities of each website from the previous post:

  • (Identity Provider/System of Record):
    • Provides login page
    • Provides logout page
    • Manages Tokens and SSO cookie.
    • Provides SlideCookie page/handler (more on this below)
    • Provides API to validate Tokens
    • Inspects SSO cookie on every page request
      • Validates Token against API on every page request (server side)
      • Automatically logs the user in if the Token is valid.
      • Automatically logs the user out if the Token is not valid.
  • and (Service Provider sites):
    • Redirects user to Login page
    • Redirects user to Logout page
    • Inspects SSO cookie on every page request
      • Validates Token against API on every page request (server side)
      • Automatically logs user in if the Token is valid.
      • Automatically logs user out if the Token is not valid.

Note: While this example has the login page on the Identity Provider only, this solution can also be implemented with login pages on the Service Provider assuming the Identity Provider offers an open API, but does require additional development work.

Technical Considerations

As you’re getting into your SSO implementation, there are a range of technical aspects that you need to consider. Here are a few items worth thinking through as part of your implementation.

Session Synchronization

  • Sliding SSO cookie and Token (Tickling) – The “tickle” to slide the SSO cookie and the Token  can be accomplished by referencing the “cookie-sliding” page or handler with an image tag  such as <img style=”display:none” src=””></img>
  • In-Process sessions between all of the websites do not have to be in synch. The SSO cookie along with the API validation will keep all of the websites informed if the user is authenticated. So a session can be restarted seamlessly for the user.

Redirect Loop

  • If you encounter a redirect loop, it is most likely related to the SSO cookie.
    • Check if the cookie is in fact being generated and has the proper Domain attribute. Fiddler is a good tool for this.
    • Check that the cookie is being sent to all of the websites. If it is not, then it might be an issue with Http to Https switching, or an inconsistent “Trusted Sites” configuration in Internet Explorer.
    • Individual users may also have blocked cookies on their browsers. Providing some basic error message text on the login page notifying them they will need to enable cookies to proceed. It may be worth analyzing your users prior to implementation to understand what percentage of your web visitors have disabled their login.

Security considerations

  • HTTPS: This is a general best practice of any website that requests or displays sensitive information. On a login page, make sure it is served over https such that communication is properly secured with a Secure Socket Link (SSL) Certificate issued by a Certified Authority (CA).
  • Secure Cookies: The SSO cookie should be flagged as a “secure cookie” by including the Secure attribute with the cookie. This instructs browsers to not send the cookie along with a request to an HTTP URL even if it is to a resource on the same domain.
  • HttpOnly Cookies: The SSO cookie should be set as “HttpOnly”, which is accomplished by setting the “httponly” cookie attribute. This helps protect the SSO cookie by instructing browsers to deny browser-side alteration to the cookie (i.e. using javascript)
  • CSRF: As with any cookie, your SSO cookie can be vulnerable to Cross-Site Request Forgery. Implementing the proper safeguards against CSRF is highly recommended. You can refer to the OWASPs cheat sheet for more info on CSRF:


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.

Synchronizing Single Sign-On (SSO) with a Domain Cookie, Part 1: An Overview

Hans_Stechl fusionSpan Team July 19th, 2018 by

There are a number of different implementations for Single Sign-On (SSO). SSO is generally approached in one of two ways – The first is a browser-side implementation which usually involves an integration that redirects the user to an Identity Provider’s login page (Identity Provider is the website that is the system of record in which the user accounts reside), while the second is a back-end integration that consumes an Identity Provider’s web services (API) to authenticate users.

New call-to-action


The usefulness of most SSO implementations tends to end at the moment of authentication. This is sufficient when all is needed is to allow users to authenticate and validate the user’s authorization. Unfortunately, for organizations that own and manage multiple websites, the challenge beyond authentication lies with “synchronizing” the login sessions of all of the websites, and maintaining a seamless user experience which would ideally look something like this:

  • Single Sign-On: When the user Logs In to any of the websites, then whenever she/he navigates or is redirected to one of the other websites, she/he is automatically logged in.
  • Single Sign-Out: When the user Logs Out of “any” of the websites, she/he is unable to access restricted content on any of the other websites. In essence, the user is Logged out from the other websites as well.
  • Session Expiration: Whenever the Identity Provider’s session “Expires,” the user should not be able to access restricted content on the other Service Provider websites.
  • When a user’s session on a Service Provider website expires, it is automatically restarted if the Identity provider’s authenticated session is still active.

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

  1. An Identity Provider website:, and
  2. Two satellite “Service Provider” websites: and

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, “”, 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: 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, 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 and (both end in 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 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 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 even if the SSO cookie and Token are expired or deleted; for this reason MUST inspect the SSO cookie and validate the Token on every request. On the flip side, if the “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.

New call-to-action

Enterprise AMS: When is a customization right for you?

justin fusionSpan Team March 29th, 2018 by

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.


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.

Syncing your sites – is it worth the cost?

justin fusionSpan Team May 13th, 2015 by
Taj Mahal Reflection
Is it worth paying to have your systems reflect the data being stored in your database?

With technology today almost anything can be automated. Yet so many organization are unwilling to invest capital to automate mundane tasks in order to save their employee’s time – updating multiple contact lists with the same information, generating website content after entering the same information in their database, etc. Why? For many organizations they view employee salaries as a sunk cost, something they were going to spend money on regardless, where as investing $7,500 in technology development is a very clear cost cutting into the bottom line. The problem with this thinking is it doesn’t take into account the opportunity cost – what could that employee have done with that time otherwise?