Many customers have protected content or a mix of protected content with public-facing content. In scenarios with protected content at play, many customers have deployed a single-sign-in (SSO) architecture to improve the user experience across multiple systems. No matter which scenario your organization falls, FUSE is designed to 'layer into' your existing security infrastructure—no changes, updates, or process adjustments required.


There are three approaches a customer can take when using FUSE to display protected content—Paywindow, IF/ELSE, and Payload—each of which is detailed as follows. Of note, the IF/ELSE and Payload approaches which allow for the secure delivery of your content also apply to personalizing content for your users.



The Paywindow Approach


In contrast to having a paywall, FUSE often suggests having a paywindow. Also known as the newspaper subscription model, users are presented with a content item—page, article, course, video—by title and abstract (one or two sentences that describe/introduce the item) and upon selection/click, your site's existing security schema kicks in.

For example, FUSE indexes a course via the API of your learning management system (LMS). That LMS is already incorporated into your organization's SSO, for example. Since FUSE fetched the content item from the LMS at the data layer/directly from the API, FUSE can send the HTTP request over to the LMS and the LMS will then determine whether to let the traffic through or funnel the user into your preexisting sign-in flow, just like any other HTTP request.

In other words, FUSE's requests for content items come through to the target systems/sources of content just like any other web traffic. 

The benefit of the Paywindow Approach is to show the value of content that's normally hidden from View:

  • For membership organizations this could mean: you should become a member because you'll be able to access this content and more. How else would the prospective member know there's good content available? Many organizations rely on the "trust us, we've got good information" model while most prospects follow the "seeing is believing" mindset. Would you buy something without being able to see an example of it?
  • For subscription-based organizations this could mean: this is the type of information you'll have available to you as a subscriber. We're giving you 'a taste' but you need to pay to gain access to the fulltext.
  • For pay-as-you-go operations this could mean: showing a preview to the purchaser of an item's fulltext to convince them to buy. 



Paywindow Variation


Same as the Paywindow approach but, for example, only showing the title of a content item without an abstract (Figure A). 

Image Placeholder

Figure A


Abstracts are usually generated by FUSE dynamically based on the first X words of a content item, an AI-generated title or description, or by the words that surround a concept the user is looking for. FUSE can also use a field you designate/specify within your content source. The latter is helpful when you've spent time writing and storing detailed descriptions of content previously.

The variation here is that FUSE can suppress these abstract snippets as depicted by the number 2 in Figure A. This has the benefit of showing the user that a content item relevant to what they're looking for exists (the goal) while also not exposing potentially sensitive information (the compromise).

Further, not all content types need to be treated the same. As in the Figure A example, this organization decided that it was OK to use the Paywindow Approach for Magazine items (number 1 in Figure A) while Discussion items (number 2) should take the Paywindow Variation route.



The IF/ELSE Approach


FUSE deploys an extensive and powerful embed framework for each FUSE instance. Each FUSE user interface is represented and rendered where you see fit by a FUSE Embed.

It's easy for FUSE to generate different versions of a customer's embed(s) based on business needs. Say you need a members-only version of a FUSE Embed and another version that's for the public/someone who is not signed-in. FUSE would generate two separate FUSE Embeds for you:


<if signed-in member then>

         Member Version of FUSE Embed

<else>

Everyone Version of FUSE Embed

</end if>

This approach works best when there is a limited number of variations (e.g. less than 5). If there are several possible permutations then that's a good use case for the Payload Approach.



IF/ELSE Variation


You're in control with FUSE. Since you have the FUSE Embed, you can place it where you see fit (as long as that "where" supports HTML and CSS). As such, you can place any FUSE Embed on an existing protected page or system and you control access to the page or system using your existing security framework. 

Of note, FUSE own's admin panel (where you can manage your FUSE instance(s)) is architected on this premise. Instead of FUSE needing to manage usernames, passwords, and access (what happens when that employee leaves your organization but no one tells FUSE?) — FUSE simply gives you your admin panel as a FUSE Embed and you place it in a secure location of your choosing where you're in control. 


The Payload Approach


This method is best when:

  1. The Paywindow Approach doesn't apply because you must tightly control who can see certain content items/know of their existence.
  2. The IF/ELSE approach won't work because there are too many possible variables/permutations of access.
  3. Access control/security as it relates to the content is paramount/mission critical.
This approach allows the passing of information to FUSE in-code, prior to the FUSE embed code. FUSE uses that information to affect what FUSE shows to the user in the FUSE embed. Please visit Pass User- or Situation- Specific Data to learn how to implement this.