Recruitment Email Automation and Candidate Notifications

When a new company is created, 16 templates are installed with it and every one of them starts active and marked default. So there is already a text ready when the first application lands; writing a template is not a precondition of setup. When you want the wording in your own voice, you fix the subject line and the body in the editor.

Every time you open the template list in the panel, missing default types are filled in. A template type added later, signed document delivery for example, is waiting for an older company the first time it opens the screen. The fill-in only creates what is missing; it never overwrites a body you edited.

Only one template per type can be the default. When you make a template default, the other one of the same type loses that status inside the same operation, so two texts never compete silently. To try new wording, duplicate the template: the copy opens with the same type, subject and body, becomes active but not default, and the live flow stays untouched.

One warning: deleting a template cannot be undone. Deletion is not soft deletion, nothing comes back from the trash. If you have given up on a piece of wording, deactivating it is the safer path.

• The templates themselves are installed for every company; the screens that trigger interview and document templates are open on the Professional and Enterprise plans
• Creating, updating and deleting a template are separate permissions; a user with view rights cannot edit
• Template operations and sends are written to the activity log, and a bulk send records how many went out and how many failed

A template body never carries the logo, company name, address, footer links or brand color as fixed values; they all sit there as placeholders. At send and preview time those placeholders are read from the company record. In practice: change your logo and templates written months ago go out with the new one, no one by one edits needed.

Brand resolution has a short lived cache, 60 seconds. A send with many recipients therefore comes down to a single company read. When you edit brand information that cache is dropped straight away, so the new logo does not wait for the next send.

The only real trap here is manual: paste your own logo URL into the body and that URL freezes, staying behind when the brand changes. Leave brand fields as placeholders while editing a template; otherwise every brand change means going through the texts by hand.

• Fields never baked into the body: logo, company name, address, footer links, brand color, year
• The editor shows the raw placeholder, the preview shows the same body with branding resolved
• Candidate email goes out with the company brand and the company SMTP setting; CV analysis, invoice and welcome emails go out with the product identity, and the two never mix

You write variables into the text and each recipient gets their own values at send time. Available variables are listed by template type and appear in the panel with a description. The job application received template carries first name, last name, full name, email, phone, position, application date and status; a document request carries the requested document list, the upload link, the deadline and the manager note.

Conditional blocks are available too. Put a field behind a condition and the whole block leaves the body when that field is empty, so no orphan line is left under a "Note:" heading.

An unknown variable name silently goes out as plain text. Filling recognizes only the names it is given; a mistyped placeholder reaches the candidate exactly as typed. That is why "check the preview" is a real warning here, and why the preview can be trusted: the preview on the send screen runs through the same code that produces the text the candidate receives.

The user moving a candidate to Accepted, Rejected or In Review is asked one question: should we notify the candidate. The dialog shows the recipient, a summary of the application, the old and new status badges and how many emails that candidate has received so far. Both options are always open, the send is never automatic. If email notifications are off for the company, the dialog says so explicitly.

AI decides nothing here. GoTeam never rejects candidates automatically: a user changes the status, and the same user decides on the same screen whether the email goes.

There are three statuses with a candidate facing template: Accepted, Rejected and In Review. Interview and Hired transitions have no template for the candidate side, so the email is skipped there. The expectation that "the candidate hears from us on every status change" is therefore wrong, and whoever sets up the screen needs to know it.

If the same transition fires twice, the candidate never gets a second message. The protection key is built from the company, application type, application id, old status, new status, template type and the update timestamp before the transition, and it is unique in the database; the second attempt returns "already sent".

The send screen takes one of three recipient sources: job applications, internship applications or manually entered addresses. Application sources come with a filter bar; status and position on the job side, status, university and department on the internship side. The recipient list you build sits on the left, content and preview on the right.

The moment you confirm, the dialog closes and the job moves to the background. You keep working in the panel and follow progress from a floating indicator in the bottom right. New sends join the queue and jobs are processed one at a time so the SMTP server is never flooded; the indicator says how many jobs are waiting. Bulk sending on the service side is sequential as well, waiting 100 milliseconds between recipients.

You can also write a one off email without a template: subject and body by hand, with brand fields still filled from the live company record.

On the permission side there are six separate rights: viewing, creating, updating and deleting templates, plus single send and bulk send. Bulk send is its own permission: the server looks for it as soon as one request carries more than one recipient, while a single recipient needs only the single send right.

The sending setup is per company. Enter your own SMTP server and it is used; server address, user and password all three have to be filled in, and if one is empty the setting never kicks in and the system SMTP setting takes over. The password is stored encrypted and decrypted only at send time. The panel reports which source is active with one of four states: your own server, the system server, undefined, off. Sender name and sender address are set separately; left empty, the address falls back to the SMTP user and the name to the company name.

When the email notifications setting is switched off nothing is sent, but no record is lost: sending falls to the empty provider and the record is marked Skipped, not Failed. That distinction is deliberate, because counting a switched off setting as a delivery error pollutes the error rate. While the setting is off, email screens leave the menu and screens such as document requests and interview invitations show the "no email can be sent" warning.

Every outgoing email is written to a record and rests in one of four states: Pending, Sent, Failed, Skipped. The record holds the recipient, subject, body, error message, attempt count and which application it belongs to. The same history appears on the candidate card and on the card of a person who has become an employee. A failed email is resent from the record with one click, and the address is resolved again on resend: if the candidate has become an employee in the meantime, the message goes to their corporate address rather than the old application address.

Let us write down what we do not measure too, because it affects a buying decision. There is no open, click or spam tracking; the record knows only whether the server accepted the message, and nothing after that. There is no general scheduler either: nothing in the product lets you say "send it on this date". The only timed flow is the interview reminder, with two windows, 24 hours and 2 hours before the interview; each window is claimed in the database, so two overlapping runs never send the same reminder twice.