9. Workflows and documentation operations
The Editorial Workflow and Content Integrity project summarizes the problem. The sections here retain the review path, stale-editor scenario, proposed safeguards, and reporting context behind it.
9.1 Editorial ownership in Umbraco
In May 2026, I reviewed initial Umbraco workflow requirements and reframed them into two clearer scenarios: content authored by a Technical Writer/Senior Technical Writer, and content authored by an approved Technical Support agent. My version distinguished formal reviewers from general commenters and clarified drafting, SME validation, peer review, ownership, permissions, and publication to dev.
The workflow was forwarded as the current documentation-production workflow to be replicated in the Umbraco Workflow plugin. Production publication remained a separate Web-team responsibility. That boundary matters: publication to dev within the editorial workflow is not the same as authority to deploy the production website.
9.2 Stale editor overwrite prevention
Testing in June exposed a content-integrity problem involving two writers opening the same topic. One could enter Workflow Drafting while the other retained an older browser copy, creating a possible later overwrite. I documented the scenario and proposed a claim/unclaim safeguard independent of workflow stages.
The proposal covered user flow, Backoffice behaviour, ownership, a suggested lock data model, server-side enforcement at save time, API considerations, workflow interaction, and permissions for override or reassignment. The purpose of an authoritative save check was to address stale sessions rather than depend only on what the browser displayed. These are proposed requirements, not a confirmed account of the deployed implementation.
After discussing the behaviour with Taylor Watson, I sent a dedicated workflow-plugin bug report on June 30. The reports identify both the overwrite-prevention document and the save-lock bug-report PDF. Those originals should be attached to support a deeper implementation case study.
9.3 Process documentation and communication
The writing process connects intake, priorities, research, drafting, reviews, publication, communication, and closure. My contributions occur at several points: scoping tickets, checking product facts, codifying release-note procedures, recording migration problems, and defining editorial ownership. This connection is why the master treats workflows as part of my writing practice.
A 2025 Help Desk discussion explored clearer notifications to Product Managers about DOC-ticket status changes because some reported missing them among other Jira notifications. The proposed Power Automate approach was questioned by IT. I retain the problem and exploration without claiming that the notification solution was approved or deployed.
9.4 Reporting and measurement
My resume records generating and analyzing monthly departmental metrics and supporting workload tracking and process improvement. The November 2024 BI-6902 account concerns a Knowledge Article Case Creation report page, case/article attachment measures, a planned enhancement, and a decision to wait before production publication. These are distinct reporting activities and should retain their periods and states.
The Codex history also records ticket-label checks for KPI hygiene, 2027.0 NPI queue counts, and analysis of the last 500 commits, diff volumes, authors, and day-of-week patterns. Such repository observations are incomplete proxies for contribution. They should not be turned into an employee ranking or a claim about how much work any colleague performed.