Knowledge article lifecycle

What it does

A knowledge article in Dynamics 365 moves through a fixed set of states — Draft, Approved, Scheduled, Published, Expired, Archived, Discarded — and only one version of an article can be Published at any moment. Versions and translations hang off a root record, so the article number a customer quotes stays the same regardless of which version or language they read.

Key facts

The KnowledgeArticle state values are Draft (0), Approved (1), Scheduled (2), Published (3), Expired (4), Archived (5), Discarded (6). Custom status reasons sit under these states; the states themselves are fixed.
An article must be in Approved state before it can be published. Approval is a separate step from publishing and can be done by a different person.
Publishing offers three options: publish now, schedule using the Publish On date/time, or leave in Draft and publish manually later.
The publish dialog also takes an Expiration Date and an Expiration Status. Once expired, the article drops out of knowledge search results — it is not deleted.
Article Public Number (articlepublicnumber) is constant across every version and every translation of the same article. It is the number you put on a portal URL. It can be auto-generated or set manually.
Major and minor versions are created with Create Major Version / Create Minor Version. The new version inherits content, metadata and permissions. Major Version Number, Minor Version Number, Language and Article Public Number are read-only on the new version.
Translations are separate KnowledgeArticle records linked back to the primary article via parentarticlecontentid. The LanguageLocale table carries 150+ languages, and the language GUIDs are the same across every Dataverse environment.
The publish dialog has a Publish Approved related translations with Article flag. Set it to Yes and every approved translation goes live with the parent.
Only users holding the Publish privilege on Knowledge Article can change a published or scheduled article.
Deleting a version sends it to the recycle bin and cannot be undone from the app.
The legacy KbArticle, KbArticleComment and KbArticleTemplate tables were deprecated on 1 December 2020. Anything you build should target KnowledgeArticle.

When to use / skip

You don't get to skip this — if the client is using knowledge at all, the lifecycle is already switched on and articles are already flowing through it. The real question is how much of it you formalise. A twenty-person service desk with three subject matter experts does not need a four-stage approval chain; they need one person who can publish and a habit of doing it. Turning on a heavy review process there just means articles sit in Draft forever and agents go back to pasting from OneNote.

Where it earns its keep is regulated or multi-brand work: financial services, healthcare, anything where a wrong published answer has a compliance consequence. Then you want approval genuinely separated from authoring, expiry dates on anything time-bound, and versioning discipline so you can show what was live on a given date.

The out-of-the-box business process flow (Create → Mark for Review → Review → Publish) is a reasonable default. Most projects either use it as-is or replace it entirely with a Power Automate flow driven off status reason changes. The middle ground — customising the BPF heavily — tends to age badly.

Configuration decisions

Whether approval is a separate role from authoring, and if so who holds the Publish privilege. This is the single decision that shapes everything else.
Whether article numbers are auto-generated or supplied from an existing external KB. If you're migrating, decide before go-live — the number is meant to be stable and customers will have it in old emails.
Default expiry policy: do articles expire by default, and after how long? Most clients say yes in the workshop and then never set a date on anything, so decide whether you enforce it with a flow.
Whether the shipped business process flow stays, gets replaced by Power Automate, or gets removed entirely in favour of status reasons plus a queue.
Custom status reasons under the standard states — worth doing for "Needs Legal Review" or "Awaiting Product Sign-off", but keep the list short.
Whether translations are managed in-product or exported to a translation vendor and re-imported. That decision drives whether you need the translation subgrid on the form at all.

Gotchas

Only one version can be Published. Create a major version of a live article, publish it, and the previous version drops to Archived — agents mid-conversation with the old version open will be looking at stale content.
Draft state is not a security boundary. statecode describes where the article is in its life, not who can see it. Anyone with Read on KnowledgeArticle can read drafts. If draft content is sensitive, that's a security role problem, not a status problem.
Expiry silently removes the article from search. Nobody is notified. Build a view or a flow on articles expiring in the next 30 days or you will discover the gap when an agent does.
Language cannot be changed after the article is created. Author in the wrong language and you are recreating the record, not correcting it.
The articlepublicnumber sequence is environment-specific. A dev-to-prod solution move does not carry it, and article numbers in a refreshed sandbox will not match production.
Scheduled publishing depends on the platform's async job. It fires close to the time, not exactly on it. Do not promise a marketing team a 09:00:00 launch.

Consultant notes

Demo the version-and-publish cycle early, with the client's own article. The moment they see the old version go to Archived, the governance conversation starts on its own.
Push back hard on multi-stage approval for small teams. Ask them who will actually click Approve on a Tuesday afternoon. If there is no name, cut the stage.
Before go-live, check that at least one non-administrator security role has the Publish privilege. Clients routinely discover on day one that only the sysadmin can publish.
Agree a review cadence and put it in writing — an owner per category, a re-read interval. The product will not chase anyone.
If you're migrating from an external KB, map old article IDs into a custom field as well as the public number. You will need it for redirect rules on the portal.

Worth another look if Microsoft changes the version/publish behaviour, or if the client adds a second language after go-live.