If your web site uses only static resources then you do not need the Filter. Even if your site is login-protected, as long as there is no need (during a visitor-engagement session) to access either dynamic resources or protected resources then you do not need the Filter.
If, however, you have any resources at all that are protected or dynamically generated then you will need the Filter. There are associated advantages to using the Filter but the technical requirement rests solely on the nature of the resources that will be accessed during visitor-engagement sessions.
Note: If, for whatever reason, you do not wish to use the filter but still need to protect some online assets, there may be workarounds. See Managing Restricted Resources Without the Filter to find out if there is an appropriate workaround for your particular case.
Note: The filter is not required if you are sure you will never need to view session-specific data/images during a co-browsing session. This seems simple enough but it can be tricky to discern whether you will need the filter for session-specific resources. Make sure you are aware of what is ‘session-specific’ and what is not. In general, all personal or customer-specific data, especially in graphical form, is session-specific. See Session-Specific Content.
The nature of your use cases will determine whether you will need the Filter or not. For example, if you have a public web site (with no login requirement) and all resources are open and available to all visitors then the Filter is not required. This is the simplest case; with no protected resources nor any dynamically generated content to worry about the Agent can see what the visitor sees. However, it should be borne in mind that such a use case strongly implies a site with a lot of traffic. So, while the filter would not be required to perform the technical machinations that enable the Agent to see potentially sensitive information or access protected resources, the bandwidth efficiencies might make the Filter an attractive option (as the Filter would only inject the code snippet when a co-browsing session is started).
As use cases become more complex we must assume that there will be personal or sensitive data that will be shared during a session. For example, loans, mortgages, credit cards; everything that constitutes retail banking, can only be handled with static resources up to a point. That is; one might be able to engage with visitors, help them, direct them to offers or deals or other information that builds relationships, but when you need to actually do some business with visitors then you may need the Filter.
For example, as we move up the ‘engagement hierarchy’ to investment banking or trade finance or mergers and acquisitions the complex engagement requirements themselves define your technical requirements. There are many complex activities that can still be performed without the Filter. For example, your analysts can share charts or offer market insight to investors or your economists can outline their recommendations and strategies using static resources. Essentially, if you want to use unblu to do marketing and general relationship management, using static resources, you would not need the Filter. You will need the Filter if you intend to make transactions such as completing contracts or selling services; any engagement that requires your agents to share personal or sensitive information that must be protected will require the filter.
The decision on when to inject what is rule based. The rules are the main configuration element of the filter. The Collaboration Server provides a JSON-based configuration, including rules and injection advice for the filter.
The core purposes of the Filter are:
Automatic uploads for document co-browsing