The capabilities of NaviPlan seem endless when you dive into the application. Sometimes it can be easy to use a feature and not appreciate its value or understand the complexity of how it might work behind the scenes. When developing software, the end goal is typically to use as much detail as possible to produce a simple and easy-to-use product. There are some features within NaviPlan that are very simple and user-friendly, but have much more going on behind the scenes. One of these features deserves a closer look.
The Fact Finder
A Fact Finder is essentially a means for an advisor to gather financial data from their client. When planning with a client, an advisor can create a Fact Finder, either with no information or populated with data from an existing financial plan, and send it to the client for completion. The client receives an email notifying them of the new Fact Finder, then logs into their account in the client portal and completes the Fact Finder. Within the client portal, the client can add, delete, or edit existing data such as accounts, expenses, assets, liabilities, insurance policies, and more. When finished making edits to the Fact Finder, the client submits it back to the advisor for approval. Upon receipt of the completed Fact Finder, the advisor can make any last edits and use the data to create a financial plan. There is a technical step of this process, however, that can be easily underappreciated.
The preview & edit step
When creating a Fact Finder, the advisor has the option to preview it and make edits before sending it to the client for completion. Likewise, upon receipt of a completed Fact Finder, the advisor can also review the data and make any last edits before creating a financial plan with this data. This is all made possible by a simple button click, but what happens after this button click is truly magical.
When the button is clicked to preview and edit a Fact Finder, a new pop-up is opened in NaviPlan to let the advisor know that editing is in progress. This pop-up locks down the NaviPlan screen to prevent the advisor from making any structural changes to the Fact Finder while it is being edited.
Immediately after this pop-up opens, a new tab is opened in the browser. This new tab loads the Fact Finder data and allows the advisor to make edits (this tab will now be referred to as the 'Fact Finder tab').
Once editing is completed and the new Fact Finder tab is closed, the NaviPlan pop-up is also closed and the advisor can resume sending or accepting the Fact Finder. Likewise, if the advisor would close the pop-up in the NaviPlan tab, the Fact Finder tab would also be closed. But how does the NaviPlan tab know when the Fact Finder tab is closed, or how does the Fact Finder tab know when the pop-up in the NaviPlan tab is closed?
When the new Fact Finder tab is opened, NaviPlan immediately gets a reference to it by using the window.open() function. 'Window' in this case describes the 'Preview in Progress' pop-up because that is the current context of the NaviPlan tab. The Fact Finder tab also gets a reference to the NaviPlan tab by using the window.parent property. By having references to each other, both the NaviPlan and Fact Finder tabs have the chance to communicate with each other. Both the NaviPlan tab and the Fact Finder tab set a property called 'window.onBeforeUnload' to post a message to the other tab when it is closed. Both tabs also become listeners for this message.
As you can see in the code fragment below, the 'Preview in Progress' pop-up first loads the Fact Finder tab with window.open(). Then, the pop-up sets window.onBeforeUnload to run the 'close_preview_and_edit_tab' function when it is about to close. Lastly, the pop-up adds an event listener to listen for the 'message' event from the Fact Finder tab.
var fact_finder_tab = null;
fact_finder_tab = window.open("https://www.previewfactfinder.com"); //'window' is a reference to the 'Preview in Progress' popup
window.onBeforeUnload = close_preview_and_edit_tab; //when this popup closes, close the preview_and_edit tab
//executes when message is received
function receive_message( event )
if(event.data == "close_editing_in_progress_popup")
fact_finder_tab.postMessage("event_close", "*"); //A message is posted to the fact_finder_tab with data "event_close" to tell the tab to close
Pros and cons
One con to this approach is that there are definitely some security risks if you are not careful. When posting a message, it is highly recommended that you specify the URL that will be receiving it. Not doing so allows for other listeners on the network to receive the message and any data that it might contain, which leads to another risk; You should also not add sensitive data to the message you are posting. If by some chance the message is received by a user with bad intentions, they have complete access to whatever data was included.
In this example, there are no security risks with the messages that are posted between tabs. You can see in the code fragment that the URL is not specified when the message is posted, but there is no sensitive data included in the message that makes it a security risk. The NaviPlan pop-up simply tells the Fact Finder tab that it is closing so that the Fact Finder tab also knows to close.
Though this example specifically shows how you can communicate between browser tabs, using window.postMessage is also a great way to communicate between different domains. This means that you can develop your application to communicate with other applications, iframes, or sites, as long as they are listening on the other end.
Communicating between browser tabs in the Fact Finder workflow allows for a complex feature to appear smooth and understandable to the user. It is just one small piece of NaviPlan that can be underappreciated for what is really happening behind the scenes.
To learn about the new NaviPlan APIs that enable firms to build fully customized self-directed planning experiences, click here.