Using Involve Resume

Auto-Apply vs Autofill: Which Boards Support Which

Only about a quarter of listings accept a direct submission. Which boards do, which are refused, and how the queue tells you before you press anything.

There are two ways an application can go out without you typing it, and they are not a feature and a fallback. They are two different promises, and the difference is who presses send.

• Auto-apply. The queue is submitted. Nobody is watching.
• Autofill. The queue is opened, tailored, filled to the last field the form will accept, and left there. You read it and you press submit.

They share one code path deliberately, because the moment they are two files the filling one starts doing a cheaper job on the reasoning that nobody is sending it anyway, and then it is a mail merge.

The split is decided by the boards, not by us

Measured across 5,298 live listings in the index:

So about a quarter of the index is submittable and the rest is not. "Apply to everything automatically" is not a feature anybody can build, not for want of engineering but because most employers do not accept an application that way. What can be built is: submit the quarter that is submittable, and pre-fill the rest so the remaining work is a read and a click instead of forty minutes of retyping your own address.

Which board does what

The routing is decided from the listing's own address, before anything else runs.

Two of those rows are refusals rather than gaps waiting to be closed.

LinkedIn. There is no host permission for it in the extension, the popup will not enable the button on it, the background worker refuses before injecting, the first statement of the form engine is a hostname guard, and the queue checks it again in case a list arrived from somewhere the routing never saw. The reader that draws match scores is refused there too, and that one is worth explaining: reading an advert is not automating a submission, but the rule this product keeps is that no code of ours runs on that site at all, and a generic reader is exactly the change that quietly turns a rule into an exception.

Workday. The submission needs employer-issued credentials. That is not something a tool can hold on your behalf, so those postings are flagged and handed back. The listing opens, the extension fills what the form allows, and you sign in and finish.

How you know before you press anything

Two places tell you, and they tell you at different moments.

On the listing. Every job carries what applying will actually involve while you are still deciding whether to open it. Internally there are five routes; on a card they collapse to the only distinction that changes what you have to do, which is whether you have to do it yourself.

On the queue screen. Every gate that can hold a job back runs at render, before the button, in the same order the hand-over will use. Each row carries its answer:

That last state exists because filling a form for a posting nobody will read still costs you one of the day's applications. It is named rather than silently dropped, because a job that vanished from a queue is indistinguishable afterwards from one that was sent and ignored.

Separately, every listing carries a reading of how much is known about the employer: whether the company can be named independently of the posting, whether the advert contains the phrases that correlate with bait, how long it has been open. That is a label to read, not a gate. Today it changes what the card says, not what the queue does.

There are also two stop switches. A global one demotes every unattended row on the screen to fill, for the day you want to read everything first. A per-job one does the same for one row. Both demote rather than drop: the job is still prepared, opened and filled, and the only thing taken away is the machine pressing send.

What holds an unattended application back

Three checks, and they run in this order.

1. The fit gate. It compares the industry, the trade and the level of the posting against your own history. When it cannot tell, it asks rather than guessing, and the question names both sides concretely. A wrongly asked question costs you ten seconds. A wrongly sent application costs you an employer's first impression, and nobody applies to the same job twice.
2. The resume for that kind of role. If it still has a keyword question you have not answered, no application goes out unattended. It is filled and left open instead, with the outstanding question in the run log so you read it before you send in that tab.
3. Your own exclusion rules. Six switches, kept on your account, that take whole categories out of the queue without taking them off your jobs screen: internships and working-student roles, graduate schemes, part-time and temporary, contract and freelance, full-time, and anything with no stated pay. They are exclusions rather than an include list, so a category the index adds next month is queued rather than silently dropped. Your minimum match setting applies here too, and this screen never widens it on your behalf.

What sending actually commits you to

Auto-apply is a separate switch with its own consent tick, and the tick is cleared if you leave the mode and come back, so a tick given twice is given twice.

What you are agreeing to, in plain terms:

• Documents go out under your name that you have not read first. The fabrication guard still refuses anything it cannot trace to your own resume, but a tailored line you would have reworded is a line an employer sees before you do.
• The board's own boxes get ticked for you: the privacy notice, the terms, the confirmation that the above is accurate. A form cannot be submitted without them, so agreeing to send is agreeing to those. That is a legal statement rather than a preference, which is why it is a switch and not a setting.
• The voluntary questions at the foot of a United States form are answered with the form's own prefer-not-to-say option unless you have set them yourself. That reveals no personal detail and is true whoever you are, but it is still an answer entered in your name.

What one application spends

The allowance is spent at the moment the application is customised, inside the call that writes the letter and the screener answers, and not at the moment anything is submitted. That ordering is the point. You cannot get a tailored application without it being counted, and you cannot be counted and get no document, because the plain drafts are assembled first and kept if the model call fails.

One consequence is worth knowing. A form that stops at a bot check is counted as filled rather than failed, and the allowance spent on it is given back, because the expensive half was done and the last four seconds were refused on principle. Charging for that, and charging again when you come back and finish it by hand, would be charging twice for one application.

The pacing, and why it is not a slider

Jobs are worked through twenty to forty-five seconds apart, randomised. That is not caution for its own sake. Forty submissions from one residential address inside an hour is the fastest way to get a board to start quietly binning everything from that candidate, and they never find out. A faster queue whose applications are ignored is worse than no queue.

The daily caps follow the same reasoning. They are set by what a real person plausibly does and what a board plausibly tolerates, not by what the margin would allow.

Read the route on a few listings before you queue anything, at the job board. Half the value of the label is that it changes which jobs you open first.