ASP.NET Core and accounting firm
Two shared layouts, and the one that belongs to the client portal
A practice that built its website on this stack almost always built the client portal into the same project, as an area with a shared layout of its own. That second layout decides whether the widget follows clients into the place they exchange documents, and it is a file most people never open until they go looking for why the launcher behaves differently in one section of the site.
Why this pairing is its own job
The ASP.NET Core install guide covers the tag, and the accounting firm guide covers what the assistant has to know. What follows is the part that belongs to neither.
- The public site and the portal are two halves of one project with two shared layouts, and which one a page uses is settled by a view start file rather than by anything in the page itself. Editing the layout you found first covers whichever half you happened to open.
- For this trade the boundary is not cosmetic. The portal is where accounts, returns and correspondence are exchanged, and a launcher in front of a signed in client invites exactly the questions that must never be answered: what my liability came to, whether my return has gone in.
- The material worth answering from is entirely on the public half. Fee packages, deadlines and onboarding requirements are all published, which means the crawl never needs to get past a login, and that is unusual enough to be worth naming.
- Deadline season is the reason a practice wants this at all, and deadline season is also when the portal is busiest. Settling the layout question in the autumn is worth more than any amount of tuning in January.
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 ASP.NET Core guide. Everything below is about where it goes on a accounting firm site specifically.
Find every shared layout before you edit one
A project of any size has several. An area carries its own, a view start file in a subfolder can point a whole branch of the site at a different one, and the identity pages usually have another again. Search the project for layout files and work out which parts of the site each one builds.
What you want at the end is a short list with a decision written against each entry: this one takes the tag, this one does not. Keep the list in the repository, because the next person to add an area will otherwise inherit the question without knowing it was ever asked.
Leaving it out of the portal layout is a choice, so record it as one
Not adding the tag there is the default outcome and the right one, but a default is not a decision. An area added later by somebody who copied the public layout as a starting point changes the answer, and nobody involved will have thought of it as a change.
If a client facing assistant inside the portal is genuinely wanted, it is a second assistant with its own key, its own material and a refusal written for signed in clients. One assistant answers from one body of material, and material written for a prospect asking about fees does not suit a client asking about their own file.
Confirm coverage by opening pages rather than by reading files
Open the home page, a service page, the sign in page and one page inside the portal, and look at the corner of each. Four page loads settle what a search through the project cannot, because view start files and area routing make the mapping from file to page genuinely hard to read.
Repeat it after any release that adds an area. This failure is silent in both directions: a missing launcher across half the public site, or a present one on a page where a client is reading their own accounts.
Where the answerable material lives
| Fee packages with the client profile each one assumes | A sole trader, a landlord and a limited company with payroll are three different prices, and prospects cannot tell which one they are. Packages published with the profile attached let the assistant route somebody to the right figure rather than to the lowest one on the page. |
|---|---|
| The exclusions, which are what fee disputes are actually about | What triggers an additional charge: an enquiry from the tax authority, records that arrive late, an extra return, a formation. Practices publish inclusions and keep exclusions in the engagement letter, which is backwards for this purpose, because the exclusion is what stops the assistant promising something. |
| The deadline calendar, on the page the practice actually maintains | Filing dates drive the entire enquiry pattern of this trade and they are the material most likely to go stale. Point the crawl at the page somebody updates rather than a document produced once, and read it again whenever that page changes. |
| Everything inside the portal, which stays out of the corpus | Client accounts, returns, correspondence and the practice's own notes sit behind a sign in that a crawl meets as an anonymous visitor and never passes. That is the correct outcome and needs no working around. The one thing worth moving outward is the onboarding requirement list, which clients currently discover only after they have asked. |
The first thing to get right
List the shared layouts in the project and mark which sections of the site each one renders, before pasting anything.
Everything else in this install is a single line. The only real decision is which of those files takes it, and the mapping between a layout file and the pages it builds is not visible from either end. Ten minutes with the view start files buys certainty about the one boundary that matters here, which is whether a client signed into the portal ever meets a launcher.
The failure that belongs to this combination
A launcher in the portal, in the week everybody is filing
The area was created by copying the public layout, tag included, which is how these things travel. A signed in client sees a chat launcher on the page holding their own documents and asks the question that page invites, which is whether their return has gone in.
The assistant has no practice management access and refuses correctly. What the client hears is that their accountant's own website will not tell them, in the week when it matters most, which is a worse outcome than nothing having been there at all.
The second version is quieter and costs more. Somebody asks whether an expense is allowable and receives a fluent general answer assembled from an article on the public site. It is not advice about their position and it will be read as advice about their position, which is why the caution setting and the refusal wording matter here more than the install does.
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 accounting firm 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
- Should the portal have an assistant of its own instead?
- Only if somebody will write material for signed in clients and a refusal that fits them, and it would be a second assistant with a second key. Most practices conclude that a client inside the portal wants their own file, which no assistant can reach, and that a message to their accountant is the right route.
- Our site and the portal are separate projects on separate subdomains. Does this apply?
- The boundary is enforced for you, which is the easier arrangement. What remains is the allowlist, which needs an entry for every origin a browser might actually load your pages from, and nothing about the portal needs adding unless you intend to install there.
- We added an area for a new service and the launcher vanished on those pages. Why?
- The area brought its own view start file or its own shared layout, so those pages are built from a file you have not edited. It is neither caching nor the tag. Open one of those pages, find the layout it uses, and decide whether it should carry the tag rather than pasting it everywhere by reflex.
Keep reading
- Installing on ASP.NET CorePut the tag in the shared _Layout.cshtml before the closing body tag, outside the optional Scripts section a view can supply.
- Everything for a accounting firmDeadlines drive the volume. What an accountancy practice can automate, and why no answer may touch a caller's own numbers.
- Writing that is correct for a fortnight and published for yearsDeadline and threshold posts stay live at permanent addresses. In this trade an old figure quoted with a citation reads as advice, not as a stale tip.
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.