Does the launcher survive Turbo navigations?

The tag is handed to the parser again on each navigation and the loader will not install a second copy, which is covered on the Rails install page. Nothing here needs a turbo:load listener, and adding one produces duplicate state rather than reliability.

Can it check whether somebody's timesheet was approved?

No. It reads pages and documents, and approval lives in a system it has no connection to. What it can do is state the deadline, the approval route and the pay date from your own payroll page, which is what most of those messages are actually asking.

Should we index the job board at all?

Only if you will recrawl it at the speed roles move, and only if you accept answers describing a role as of the last read. For most temp desks the answer is no. For a permanent desk whose roles sit live for weeks it can be worth it, provided the wording never asserts that a role is open right now.

Ruby on Rails and recruitment agency

Vacancies move faster than the material on a Rails agency site

Rails agency sites are usually the whole business in one application: marketing pages, a vacancy list generated from your own records, and a signed in area for workers and clients. Turbo makes that feel like a single continuous page, which is good for the candidate and produces one specific problem for an assistant, because the browsing session outlives any page the assistant was told about.

Why this pairing is its own job

The Ruby on Rails install guide covers the tag, and the recruitment agency guide covers what the assistant has to know. What follows is the part that belongs to neither.

Turbo navigations do not reload the document, so a candidate moves from the list to a role to your terms without the page ever starting again. Their questions turn positional, this one and the second one you mentioned, and there is no shared view of the page for the assistant to resolve them against.
Vacancies are withdrawn constantly. The record goes inactive, the route stops resolving, and the crawl that read the page last week is still the material. The assistant then describes a role that closed on Friday, in the agency's name, citing a page that no longer exists.
One layout covers the marketing pages and the signed in area unless somebody split it. Timesheets, placement records and client dashboards live behind a login in the same application, and the line in application.html.erb does not know which side it is on.
Payroll questions are the highest volume answerable questions this trade has, and they are usually about a portal the application does not own and cannot describe.

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 Ruby on Rails guide. Everything below is about where it goes on a recruitment agency site specifically.

Split the layout before you argue about Turbo

Look through app/views/layouts and decide about each file deliberately. The public layout carries the tag. The layout your signed in views render through does not, and the mailer layouts obviously do not.

Doing this by layout beats wrapping the tag in a condition. A layout is a file somebody reviews on the way in, a condition is a line somebody deletes while fixing something unrelated, and the failure mode is a launcher sitting on a screen showing a worker their pay.

Vacancy pages are the decision, and the tag is not

If you index the vacancy list you have taken on a freshness obligation the site itself does not have. The page is generated from your records on every request and is correct by construction. The material is a copy taken at one moment and is correct until something changes, which on a temp desk is hourly.

There are two honest positions. Keep vacancies out of the material and have the assistant answer process questions and link the live list. Or index them, recrawl at a cadence that matches how fast roles actually move, and word answers so a role is described as of the last update rather than as open now.

The tell that you chose neither is a citation that no longer resolves. Answers keep pointing at a withdrawn role, the link goes nowhere, and the candidate has already read the description twice by then.

Say in the refusal that it cannot see the page

Because the document never reloads, a visitor experiences one continuous session across half a dozen roles. Positional questions follow naturally, and the assistant has no page context to resolve them with, which is exactly the situation where a plausible wrong answer gets composed.

Have the refusal wording state plainly that it cannot see what is on screen, and ask for the role title or reference. One sentence removes an entire class of confidently wrong answers, and candidates supply the reference without complaint once they have been asked for it.

Where the answerable material lives

Source material on a Ruby on Rails recruitment agency site
Registration and compliance pages	Ordinary rendered pages, stable, and the ones carrying the documents question every registration produces. Crawlable exactly as published.
A payroll page you write yourself	Deadlines, approval, the pay run, what to do about a missed submission. Most agencies have this only inside the portal or in a consultant's head, and writing it as a page is the single largest deflection available here.
Client terms in summary	Fee basis, rebate period and its conditions, notice. Published, quotable, and the thing a hiring manager wants before they will brief anything.
Vacancy records	Rendered from your own tables per request, which is why the page is right and any copy of it is not. There is no arrangement where the assistant reads them as data: it reads the published page, or it does not have them.

The first thing to get right

Do this first

Decide in one sentence whether vacancies are in the material or out of it, and write the refusal to match that sentence.

Every other question on this site has a stable answer. Vacancies are the only moving part, and almost every complaint about an assistant on a recruitment site traces back to a role it described that had gone. Making the decision explicitly, before the first crawl, is what stops it being made accidentally by whoever set the crawl going.

The failure that belongs to this combination

The launcher on the timesheet screen, because one layout served both

A worker signs in from the public site and lands in the portal. If those pages render through the same layout, the tag is on them, and the chat box is sitting on the screen where somebody is looking at their hours.

Nothing has leaked. The assistant cannot see the page, the session or any record, and it never could. The problem is what the worker reasonably concludes, which is that this box is part of the payroll system, and what they type into it next: a shift that was not paid, a name, a tax reference.

Separate layouts fix it. Relying on nobody noticing does not, and the message you eventually read in the conversation log will contain more personal data than anything else on the site.

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 recruitment agency 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

Does the launcher survive Turbo navigations?: The tag is handed to the parser again on each navigation and the loader will not install a second copy, which is covered on the Rails install page. Nothing here needs a turbo:load listener, and adding one produces duplicate state rather than reliability.
Can it check whether somebody's timesheet was approved?: No. It reads pages and documents, and approval lives in a system it has no connection to. What it can do is state the deadline, the approval route and the pay date from your own payroll page, which is what most of those messages are actually asking.
Should we index the job board at all?: Only if you will recrawl it at the speed roles move, and only if you accept answers describing a role as of the last read. For most temp desks the answer is no. For a permanent desk whose roles sit live for weeks it can be worth it, provided the wording never asserts that a role is open right now.

Keep reading

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.

Start free See what it does