Job Descriptions FAQ
Answers to common setup and operating questions about Job Descriptions.
For what the app is and how to set it up from scratch, see the
Job Descriptions Overview.
Setup
Do I have to set anything up before I can write the first job description?
Yes — your job titles. A job description is always written for a title, so the title has to exist first, under Job Titles & Families. The Library lists every active title and shows which ones have no description yet; that list is your work queue. Family, level, pay grade, code and competencies are read from the title and never re-typed into the document.
Who can create, publish and read job descriptions?
Four tiers, and everyone falls into at least the last one.
- Admins — business and super admins, plus anyone granted App admin for Job Descriptions. They author, publish, archive, import, run the Acknowledgments report and campaigns, and change settings.
- Contributors — anyone granted Contributor for Job Descriptions. They write and edit descriptions, run the compliance check, restore an earlier version into the working copy, and submit a description for approval when a publication workflow is set up — with no workflow, they mark a draft Ready for an admin to publish, which tells the app admins and shows on the description who marked it ready and when. They cannot publish, archive, import, see the Acknowledgments report or change settings. Admins and Contributors are the only people who see drafts and unpublished edits, apart from an approver reading the description they have been asked to approve; everyone else reads published versions only.
- Supervisors — anyone with people reporting to them, directly or further down. They read the published description of any title held by someone in their reporting line.
- Employees — everyone reads the published description for their own title, on desktop or on their phone, and acknowledges it when asked.
Granting App admin is how you hand day-to-day ownership to an HR partner without making them a business admin; granting Contributor lets someone draft descriptions while an admin keeps control of what goes live. Both are granted on the app’s Admins & Contributors page.
Permissions and access
Why can’t a supervisor open the job description for someone outside their team?
Because a supervisor’s reach is their own reporting line. They see the published description of their own title, plus every title held by someone below them in the reporting tree — nothing else. If the person genuinely reports to them, check that the reporting relationship is set on the employee’s profile and that their membership is active.
I finished editing — why do employees still see the old version?
Editing never changes what employees see. Your edits are held as an unpublished revision that only admins and Contributors can open; employees keep reading the last published version until you publish again. The document page tells you this directly, with a link to the version employees are currently reading.
Day-to-day
What happens when I publish a job description?
Publishing does four things in one step.
- It freezes a full, permanent version — every section, plus the title’s family, level, pay grade, code and competencies exactly as they stood that day.
- It records who published it, when, and the change summary you typed.
- It makes that version the one employees see.
- Unless you clear the checkbox (or Ask current job holders to acknowledge each published version is off in Settings), it asks every current job holder who can open the app to acknowledge it, with a due date and reminders.
A description needs a position summary and at least one essential function before it can be published.
I only fixed a typo — how do I publish without asking everyone to sign again?
Clear the Ask current job holders to acknowledge this version checkbox in the Publish window. The new version still goes live, and nobody is asked afresh. Each holder who already has an open request keeps it — the request simply moves onto the new version, with the same due date. Nothing is lost and nothing doubles up. Leave the checkbox ticked for any change that alters what the job actually is.
With an approval workflow, the same choice is made when you Submit for approval: add a short What changed? note for the approver and job holders, and tick Don’t ask job holders to acknowledge it again for a correction that does not change the job. The choice is applied when the approval publishes.
How do I ask every job holder to confirm their description again when nothing has changed?
Start a re-acknowledgment campaign from the Acknowledgments tab. It asks every current holder in scope to confirm the version already published — no content change of any kind. Two rules matter:
- People who already have an open request are skipped, so they never get two asks for the same thing.
- People who signed earlier are asked again, and their earlier signature stays on record.
Scope the campaign to every published description or to selected titles. You also set the days to acknowledge and can add a note that shows on the report. The confirmation message tells you how many people will actually be asked, not how many hold the titles.
Can re-acknowledgment happen automatically on a cadence?
Yes. In Settings, set Re-acknowledge every N months. The default is 0, which means off; the range is 0 to 60 months. With a cadence set, one campaign opens per calendar month. It asks every job holder whose last signature is older than the cadence to confirm their current description again, and every holder who has never acknowledged it. People with an open request are left alone, and someone whose earlier request was withdrawn is asked once the cadence has passed since that request. These campaigns appear on the Acknowledgments report alongside any you start by hand.
We reviewed a job description and nothing needs to change — how do I clear “review due”?
Open the description and use Mark as reviewed in the “Due for review” note at the top of the page. It is there for app admins — the same people who publish. It records that the description was reviewed, by whom and when, and restarts the review clock from that day: the Published · review due badge clears in the Library, the review reminder stops, and the next review falls due after your Flag for review after interval. No new version is published and job holders are not asked to sign again. If something does need to change, edit it and publish an updated version instead — that restarts the clock too.
Does publishing need approval first?
Only if your organization sets that up. Add an approval workflow for Job Descriptions with the Job description publication trigger, under Admin → Approval Workflows. With a workflow in place, you submit for approval instead of publishing, and approved content publishes automatically — no second click. With no workflow, publishing is direct. Settings shows which of the two states you are in.
An approval covers the exact content the approver saw. Edit after approval and you need a fresh approval.
Why can’t I edit this job description right now?
Almost always because an approval request is open, which locks the content. That is the promise the approval makes: the approver signs off on this text, not on whatever it becomes afterwards. Use Withdraw approval request on the document page to unlock it, edit, then submit again. The same block applies to restoring an old version while a request is open.
If you see no Edit button at all, you are reading as an employee or supervisor rather than as an admin or Contributor. Use Suggest a change instead.
Can I go back to an earlier version?
Yes. Open Version history, pick a version, and restore it. Restoring copies that version’s content into the working copy and records the move as a new entry — history itself is never rewritten or deleted. Restoring does not publish; review the restored content and publish it when you are ready. Every version is kept indefinitely, and any two can be compared side by side, section by section.
Authors can also compare unpublished edits with what employees read now: Compare working copy with live on Version history (or on the description itself while it has unpublished edits) shows the working copy beside the live version before you publish or submit it.
How do I bring in our existing Word and PDF job descriptions?
Use the Import tab. Upload up to 50 files per run in Word (.docx or .doc), PDF, or plain text. Each file is read, split into the structured sections by an AI model, matched to one of your job titles, and saved as a draft — imports never publish anything. The run happens in the background and finishes with a notification listing what was created and what was skipped. Because the AI model is the only reader, the Import tab takes no files while Let bulk import use AI to read uploaded files into structured job descriptions is off in Settings.
If your descriptions already live in spreadsheet columns rather than documents, use the Job descriptions target on the shared Smart Import page instead.
Why was one of my import files skipped?
The notification lists every skipped file with its reason. The reasons are:
- No matching job title. The notification names the title, and the code when the file had one. Add that title under Job Titles & Families, then import the file again. Matching tries the position code first, then an exact title name, then a partial name match.
- That title already has a description. Existing work is never overwritten by an import.
- No readable text was found in the file.
- The document could not be split into job-description sections.
- The file was read, but the draft couldn’t be saved — the reason the save was refused follows.
- Word/PDF import is switched off. Let bulk import use AI to read uploaded files into structured job descriptions was turned off in Settings after the upload. Turn it back on and upload the files again.
- The upload couldn’t be read back from storage. Upload that file again.
- Couldn’t import this file, followed by the error — for example, when your workspace’s AI usage limit stopped the AI reading it.
If the AI reading service itself is unavailable, the run is retried. If it stays unavailable, you get a notification saying the import stopped, naming any drafts that were created before it did; the uploaded files are not kept, so upload the rest again.
A created draft can carry a note too: when the file was long and only its first 24,000 characters were read, when the title was matched only by a partial name, or when more than one job title matched. Open the draft and check it against the original, and that it sits on the right title.
Does the compliance check stop me from publishing?
No — it is advisory in every case, and the author decides. Check this job description scores the working copy out of 100 and lists findings by severity, and the panel separates two kinds:
- Rule findings are deterministic and repeatable: ADA shape, overstated physical demands, FLSA and EEO completeness, biased or exclusionary language, reading level, and pay-transparency readiness.
- AI review findings are advisory suggestions and may differ between runs. They are labelled with an AI badge. Clarity, vagueness and jargon notes from the AI review never rise above Low severity. Only protected-group language and absolute physical requirements written into prose can carry a higher one.
The reading-level check flags anything above a 12th-grade reading level. Only the prose is graded — the demand grids are not sentences, so they are left out.
Why don’t I see “Create posting in Job Board”?
Four conditions have to hold. The description must be published, because the posting is built from the published version rather than the working copy, and it must not be archived. Job Board must be enabled for your workspace. And you need admin access to Job Descriptions and the right to create postings in Job Board — a business admin, an HR admin, or a Job Board app admin. A delegated Job Descriptions admin without Job Board access does not see the option.
When it runs, it creates a draft requisition linked to the same title, built from the published version, so the posting starts from the approved record. The recruiter tailors and publishes it in Job Board. It is a one-time copy: later edits to the description do not reach the posting. If the description shows the pay grade’s range, the posting inherits it too. While a draft posting for the title is still sitting in Job Board, Create posting opens that draft instead of creating a second one.
Someone spotted a mistake but can’t edit the description — what can they do?
They use Suggest a change on the document page, or the Suggest a change link on My Job Description. It is the only door for readers, who cannot edit. The note is limited to 2,000 characters and is kept on the document. The person who wrote the description and whoever last edited it are notified, as long as they can still author job descriptions, along with anyone in the group chosen under Who else receives Job Descriptions admin notices in Settings. When that leaves nobody, the app’s admins are notified instead. A document keeps 50 suggestions; past that, the oldest answered one makes room first. Authors see a panel on the page with open suggestions first, each with its author, the version they were reading and the date, and they mark each one Done or Not changing. The person who suggested it sees their own suggestions under Your suggestions on the same page, with that answer, and is told when it is answered.
When something looks wrong
“My Job Description page is empty — where is mine?”
One of three things, and the page says which.
- No job title is set on your profile. Ask your administrator to assign one; your description appears there once it is published. For admins: set the person’s Job Title on their employment profile. If the title has a published description, it shows on their page straight away, and with Ask new hires and transfers to acknowledge their job description on, they are also asked to acknowledge it.
- The description for your title has not been published yet. It appears here once HR publishes it, and you are asked to acknowledge it if HR asks holders to sign.
- It was archived. Your acknowledgment history is kept, and a new description appears here if HR publishes one.
“I already signed this — why am I being asked to acknowledge it again?”
Two situations ask a second time, both on purpose.
- A new version was published. Each signature is pinned to the exact version it was given for, so a new version means a new request. That pinning is what makes the record defensible.
- A re-acknowledgment campaign is running. It asks you to confirm your current description because time has passed. The notice tells you whether anything in it has changed since you last signed — or that you haven’t acknowledged a version of it before — and your earlier signature is untouched.
Acknowledging closes the request immediately, along with any reminder sitting in your inbox.
“I keep getting reminders about my job description — when do they stop?”
Reminders begin three days after the request is sent. Until the deadline they repeat on your organization’s reminder cadence — every 7 days unless an admin changed it in Settings. Once the deadline has passed they come every 3 days. They stop eight weeks after the request was sent. Acknowledging stops them at once. They also stop if the description is archived, or if a newer version supersedes the request. Past the eight weeks the request sends nothing further, but it still shows as outstanding on the admin report. If an admin set the reminder cadence to 0, no reminders are sent at all.
Nobody was asked to acknowledge the version I just published — why?
Work through these in order.
- The app isn’t published to users yet. Nobody who can’t open the app is asked to acknowledge, and publishing the app later does not go back and ask them. The Library and Settings pages show admins a notice while this is the case. Publish the app to users (Admin → Apps → All Apps, the app’s page, Publish to users), then start a re-acknowledgment campaign from Acknowledgments to ask the people who were skipped.
- The checkbox in the Publish window was cleared. That is the “minor edit” path — the version goes live and nobody is asked afresh.
- The setting is off. Check Ask current job holders to acknowledge each published version in Settings.
- Nobody currently holds the title. Only active people holding that title are asked; service and AI-agent accounts are never asked to sign a job description.
- They were already asked for this same version — requests are never duplicated for the same person and version.
Why does the acknowledgment report show a different number of people than currently hold the title?
Because the two columns count different things, deliberately. Holders (Current Holders in the CSV export) is who holds the title today. Requested is how many acknowledgment requests exist for the published version, and Signed (Acknowledged in the CSV) is how many of those are signed. These things make Holders and Requested diverge:
- Someone took the title after the version was published, and Ask new hires and transfers to acknowledge their job description is switched off.
- The publisher cleared the ask checkbox for that version.
- Some holders couldn’t open the app when the version was published — for example, before it was published to users — so they were not asked.
Someone who was asked and has since moved to a different title counts in neither column. Their request and any signature stay on the record, and on the per-person CSV.
What happens when I archive a job description?
Employees stop seeing it, and any acknowledgment still waiting on them is closed out as no longer required. Everything else is kept: past versions, past signatures, and the employee’s own acknowledgment history. Two follow-ons are worth knowing. An archived description cannot be published as-is — restore a version first, which returns it to draft. And you cannot archive one while an approval request is open, so withdraw the request first.
Licensing and limits
Does Job Descriptions need a licence, and who turns it on?
Yes. Job Descriptions requires a licence and is off by default for every workspace — nobody gets it without opting in. A business admin enables it from Admin → Apps → All Apps, then clicks Publish to users on the app’s page — until then only admins and people with a role in the app can open it. They can then delegate day-to-day ownership by granting someone App admin for the app, or let someone draft descriptions by granting Contributor. Pricing and packaging live on the app’s directory listing.
What are the limits and default values?
| Setting or limit | Value |
|---|---|
| Job descriptions per job title | One |
| Versions kept | Unlimited — nothing is pruned |
| Ask job holders to acknowledge each published version | On by default |
| Ask new hires and transfers to acknowledge | On by default |
| Days to acknowledge | 14 by default; accepts 1–365 |
| Re-acknowledge every N months | 0 (off) by default; accepts 0–60 |
| Campaign days to acknowledge | Starts from your Settings value; accepts 1–365 per campaign |
| Campaign name and note | Name up to 120 characters; note up to 1,000 |
| Remind about an outstanding acknowledgment every N days | 7 by default; accepts 0–90 (0 = no reminders). Reminders start 3 days after the request, repeat every N days until the deadline, then every 3 days; they stop 8 weeks after the request |
| Escalate overdue acknowledgments to the employee’s manager | On by default; the manager is told once the deadline passes, then every two weeks while it stays open |
| Tell job holders when their description changes without asking them to sign again | On by default |
| Tell the owner when a published job description is due for review | On by default; repeats every 30 days until a new version is published or an app admin marks it reviewed |
| Send Job Descriptions admin notices to this group | None by default. The group is added to whoever a notice goes to first — the description’s author (for a suggestion, its last editor too) or the campaign’s starter. When that person has left or lost access, the group is told instead of the app’s admins, and a draft marked ready to publish goes to the group’s members who can publish it instead of the app’s admins (when none of them can, to the app’s admins after all) — so add anyone who should still hear of these to the group. With no group, an empty list falls to the app’s admins |
| Flag for review after N months | 12 by default; accepts 0–120 (0 = never flag) |
| Show the pay grade’s range on new job descriptions | Off by default |
| Job Descriptions AI assistant in Ask AI | On by default |
| Let the compliance check use AI to review wording for bias and ADA risk | On by default; off, the check runs its rules only |
| Let bulk import use AI to read uploaded files into structured job descriptions | On by default; off, Word/PDF import stops working |
| Offer AI describe-to-fill on the job description form | On by default |
| Default reasonable-accommodation statement | Up to 2,000 characters |
| Suggestion from a reader | Up to 2,000 characters; the 50 most recent are kept per document |
| Bulk Word/PDF import | Up to 50 files per run |
| Accepted import file types | Word (.docx, .doc), PDF, plain text |
| “Published · review due” state in the Library | Last published or last marked reviewed longer ago than Flag for review after (12 months by default); the Library’s State filter uses the same words. It clears when a new version is published, or when an app admin uses Mark as reviewed on the description’s page — that restarts the review clock with no new version and doesn’t ask job holders to sign again |
| Percent-of-time across essential functions | Cannot exceed 100% |
| Demand frequencies | Never, Occasionally, Frequently, Constantly — leaving an activity at Never omits it |
| Export formats | PDF, Word (.docx); Library and Acknowledgments export to CSV |
More help
- Job Descriptions Overview — what the app is, how it fits together, and what to set up first
- Job Titles & Families — where titles, levels, pay grades and competencies are maintained
- Job Board Overview — what happens to a posting created from a published description
- Ask AI — the read-only Job Descriptions assistant finds a description, summarizes its duties, runs the compliance check, and lists who has not acknowledged, always scoped to what you can already see