Angular and fintech app
One index file for the whole product, and the sign in screen it puts a launcher on
An Angular workspace produces a single document that the router fills and refills for the life of a session. That is why the install is one line, and it is also why this pairing is harder than the install makes it look: a financial product wants the widget on the pages that explain fees and nowhere near the screens where somebody is looking at their own money, and there is no file in the project that draws that line.
Why this pairing is its own job
The Angular install guide covers the tag, and the fintech app guide covers what the assistant has to know. What follows is the part that belongs to neither.
- The index file is the document for every route in the workspace. The router replaces views inside it and never produces a second one, so a tag placed there is present on every screen the application has, and there is nowhere else it could go.
- The only screen an unauthenticated visitor reaches is the sign in screen, and the person standing on it is usually locked out. Everything they want to ask is about their own account, which is precisely what an assistant on a regulated product has to refuse.
- Scoping it therefore means code: creating the element from a component and calling the destroy method on the global when the route moves somewhere it should not be. On a codebase that goes through change control because it moves money, that is a product change for a website feature.
- The material that is genuinely safe to answer from, fees, limits, timings, what verification accepts, is almost never in this workspace. It is on a separate public site, on a separate origin, usually maintained by different people.
What changes about the install here
<script src="https://cdn.askably.xyz/w.js" data-key="pk_live_YOUR_KEY" defer></script>The tag is the same one on the Angular guide. Everything below is about where it goes on a fintech app site specifically.
Decide whether the application is a surface for this at all
For most regulated products the honest answer is that the assistant belongs on the public site and stops there. Behind the sign in every question is about one person's account, and the assistant holds no view of any account and cannot be given one by indexing more pages.
That is not a reason to skip the install. It is a reason to do the install in the other codebase first and to treat putting it in the application as a separate decision that has to be argued for on its own.
If it has to be inside the application, the boundary is written in code
There is no equivalent here of moving a tag down a level. One document serves every route, so having the widget on some routes and not others means a component that creates the element and removes it again through the global's destroy method as the router moves.
That is supportable, and it is runtime logic in an application where runtime logic is reviewed by people who did not ask for a chat widget. Agree the list of routes that are in scope before anybody writes it, because the list is the part that gets argued about later.
A separate deployment for the public pages avoids all of it, which is where most firms end up anyway. If the marketing site is already its own project, the boundary exists for free and the only remaining task is an allowlist entry for each origin.
The public site is the half with anything to read on it
A crawl pointed at the application receives the same shell for every URL beneath it, because the shell is the document and everything else arrives afterwards. No crawl setting changes that, and there would be nothing worth indexing even if one did, since what those routes render is one customer's data.
So the corpus is the public site: the fee schedule, the limits, the timings, what verification accepts. That site is a different origin from the application, and it needs its own entry on the allowlist whether or not you ever install inside the product.
Where the answerable material lives
| The fee schedule, the limits and the payment timings, all on the public site | Fixed published terms rather than facts about a person, which is what makes them the safe half of this trade and the largest answerable block on it. They also sit in a different codebase from the application, so indexing them has nothing to do with this project beyond agreeing which origin the crawl reads. |
|---|---|
| What verification accepts, published in full and stopping there | Which documents are accepted, what a proof of address has to show, how to resubmit. The requirements are publishable and generate enormous question volume. Why one particular check did not pass is not publishable and must not be reasoned about, so the material has to end exactly where the published requirements end. |
| The help section inside the application, which is a route rather than a page | Financial products often keep their clearest explanatory writing in an in-application help area. Every URL in it returns the same shell to anything reading pages, so if that writing is to be answerable it has to be published on the public site or uploaded as documents. |
| The sign in screen, which is the only public screen and carries almost no text | A launcher inside the application spends most of its life here, in front of somebody who cannot get in. There is nothing on the screen for it to answer from, and the questions typed on it, why is my account locked, why did the code not arrive, are among the ones it must never attempt. |
The first thing to get right
Install on the public site first and leave the application's index file untouched until somebody has made a case for it.
The two halves of this pairing are not equal. The public site carries every question the assistant can answer and the application carries almost none of them, so installing in the application first buys a launcher on a login screen and a conversation log made of account questions. The other order gives you a working assistant in an afternoon and leaves the harder decision for a day when there is evidence to take it with.
The failure that belongs to this combination
A chat launcher on the login screen of a bank
It is the one screen the application shows to somebody who is not signed in, and the people looking at it are the people who could not sign in. A launcher there reads as help with getting in, which is the single category the assistant cannot touch: it cannot see whether an account is restricted, cannot say why a check failed, and must not speculate about either.
The cost is not the refusal, it is what a refusal costs at that moment. Somebody locked out of their own money has been turned away twice, once by the login and once by the thing that looked like help, and the second one is the one they describe to other people.
If the widget is going into the application, exclude the authentication routes explicitly and make that the first thing the code does rather than the last. If that is more work than it is worth, then the application does not get the widget, which is a perfectly respectable outcome and the one most firms should reach.
Before you go live
- The origin the page is served from has to be on the allowlist for that assistant, or nothing renders and the browser console says which origin was refused. An apex domain and its www are two different origins to a browser, so list both, along with any staging or preview host you want it to work on.
- Open the site as a visitor would, on the pages a fintech app visitor actually lands on, and ask it something only your own material could answer. A widget that renders is not the same as a widget that has read anything.
Questions
- Can we scope it by route without touching application code?
- No. One document serves the whole workspace, so no file applies to some routes and not others. The three options are the whole application, none of it, or a component that creates the element and calls the destroy method on the global as the route changes.
- Our public pages are in the same workspace as the product. Does that help?
- It makes it harder rather than easier, because those pages return the same shell as everything else and so contribute nothing to a crawl either. Publishing them somewhere that serves their text is the fix, and it hands you the boundary at the same time.
- Could it at least explain why an account is locked?
- It can give the published reasons an account can be restricted and what a customer is asked to do next, from your own material. It cannot say why this one is, and it must not offer a theory. Firms are deliberately unspecific about failed checks, and an assistant guessing in your name undoes that on purpose.
Keep reading
- Installing on AngularPaste the tag into src/index.html. The scripts array in angular.json is the wrong place: bundling drops the data attribute the loader needs.
- Everything for a fintech appFees, limits and identity checks are safe ground. Balances, transactions and anything reading as a personal recommendation are not.
- Getting a third party script past the policy a regulated product ships withThe policy decides whether the tag runs at all. Script and frame directives both matter, and a report only header proves nothing.
- Publishing a financial promotion with a single buttonThe number sits in one element and the sentence that qualifies it in another, and publishing a financial promotion here is one button anyone with access holds.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.