Promotion & Upgrade Requests

Promotion & Upgrade Requests defines the Growth-stage Develop workflow for promotion, grade upgrade, role change and salary revision requests. Require written evidence, route a request by grade, and retain the decision and effective date in the same record. The sequence covers submission, criteria checks, approval, decision and subsequent people and payroll updates. Keeping justification, review evidence, proposed changes and the decision together prevents the reasoning from being lost across emails. The register supports a traceable request process without making the employment decision.

The default deliverable is a short recommendation. An explicit setup, build or conversion request produces artifacts after essential missing facts are resolved. Advice receives a direct answer, while a review works from the material provided. This keeps the size of the proposed setup tied to the requested outcome.

Use it when promotion reasoning disappears in email or internal mobility and pay revision requests need consistent evidence and approval records. It does not decide promotions, change pay or calculate payroll. Implementing an approved decision remains a separate authorized action.

This is an empty-template workflow, not processing of real employee or customer records. Automation, reminders and synchronization require the separate integration layer. Sensitive decisions and adjustments require qualified human review before anything is acted on.

First establish who may request, then frequency, then whether grade or role changes are included, asking these separately and resolving an ambiguous requester answer before proceeding. Ask about fixed criteria, performance scores and time in role; approval levels and effective-date ownership; current delays; and whether a form, approval workflow or record is needed. Questions are asked one at a time, excluding anything already answered in earlier messages. Unknown facts stay unknown. Intent, confirmed facts, open questions and requested formats remain internal unless the user asks to inspect them; no missing answer is invented.

The field model includes Request Title (text); Employee Name (text); Department (text); Request Type (select); Current Job Title (text); Current Grade (text); Requested Job Title (text); Requested Grade (text); Requested By (text); Justification (text); Linked Performance Review (relation); OKR Score (number); Behaviour Score (number); Courses Completed (text); Time in Role (Months) (number); Criteria Met (checkbox); Current Salary (currency); Proposed Salary (currency); Currency (text); Increase % (number); Approver (text); Decision (text); Effective Date (date); Status (select); Upgrade ID (id).

Request Type starts with Promotion, Grade Upgrade, Role Change, Salary Revision. Status starts with Submitted, Under Review, Approved, Declined, Implemented.

Requested CSV, SQL DDL, JSON Schema and Notion mappings derive from one field list. Display names remain identical across CSV and JSON, and normalized SQL identifiers are documented. Relation fields keep their relational meaning, dates remain dates and money remains currency. Machine-readable data is separated from explanation, with validation failures and limitations reported separately.

One supplied SQL example is:

CREATE INDEX idx_promotion_upgrade_requests_status ON promotion_upgrade_requests (status);

Excel-compatible CSV uses UTF-8 with a byte order mark. Because CSV has no column types, numeric, date and currency formatting is identified after the data. A CSV is not an .xlsx workbook; the latter is generated only when requested. Example rows require an explicit request and must be clearly synthetic. Sensitive identifiers are not unnecessarily repeated in a review, and generated templates remain empty.

Notion output goes to notion-manual-import for the CSV, property mapping, import steps and verification checklist. Manual mappings require no connection. Requested workspace changes require verified tool access, the actual target and authorization; a claimed connection is insufficient evidence. Notion relation columns resolve only after both databases have been imported. Select options are an initial vocabulary that can be renamed to match the business. people-directory supplies the related employee master record; notification-reminder-hub is the separate due-date reminder module. Personal identifiers and sensitive financial details stay out of generated templates.