1. Plan the configuration and entry points

This guide describes the implemented Support workspace and its existing Service Desk dependencies for release 2026.10.1.0. Make configuration changes through the organisation's authorised administration process. A route or visible button is not a substitute for menu security, module licensing, workflow access or membership. Record current values and test with representative employee, first-line, second-line and administrator accounts before rollout.

1.1. Navigation and version routing

Menu captions are configurable. Existing Service Desk menus include Service Desk DashBoard, Re-Assign Query to Support User, Log Query For Employee and Log a Call. Version configuration can redirect these routes to the modern workspace through loading.aspx?RDir=HRFSupport.aspx. A user may therefore see a familiar Service Desk caption while receiving the modern screen. Open the setup page through the permitted administration/menu entry; do not distribute a private host URL as a way around access controls.

1. Inventory the installed release and identify the current menu entry, workflow template and intended support audiences.
2. Check the Service Desk module licence and the normal authenticated user/employee context. Legacy capture explicitly checks the SD licence and expiry.
3. Record existing ServiceDesk, document and optional Assistant/Chatbot2 settings before changing them. Preserve organisation-specific values.
4. Choose a pilot workflow and test account set. Test personal visibility separately from assigned visibility and Knowledge-editor access.
5. Confirm notification recipients and delivery configuration before saving a request during acceptance testing. A real capture can start a workflow and send notifications.

2. Set the Service Desk foundation

2.1. Settings managed by Service Desk setup

The setup screen loads existing HRF_MYFOCUS_SETTING rows and updates changed values when saved. The usual routing category is ServiceDesk within module ServiceDesk. General contains Version and legacy display/sort settings. Two-argument accessors also exist in older code, so preserve the installed key and category conventions rather than creating similarly named duplicate rows.

2.2. Other installed keys and legacy readers

The basic setup form validates the administrator role, super-user group, workflow, redirect step, close step, document type and administrator email. Correct a highlighted selection before saving. Workflow-step selectors are rebuilt from the selected template's XML, so a step ID from another template is not interchangeable. Refresh configuration through the organisation's normal application/cache process and reopen the screen when verifying a changed value.

3. Configure routing, first-line intake and access

3.1. Separate the access layers

1. Select a workflow mapping whose application/module are Service Desk. Inspect its initial destination and the configured redirect/close steps.
2. Populate the intended support roles/groups and memberships through the established user/group/role administration pages.
3. Sign in as a first-line agent and create or receive a controlled acceptance request through the normal capture path. Verify its reference, destination and assigned visibility.
4. Verify that a second-line specialist sees the intended assigned work after a permitted reassignment and that an unrelated user does not receive broader work.
5. Test a super user separately. Confirm that the employee still sees their personal record and only the intended public response.

3.2. Workflow variables and handoff

The modern capture path creates a workflow procedure and initial step, then writes variables including Comp_Code, Emp_No, Employee, Created_By, Requested_By_User_ID, Reference_No, CallID and Call_Details. These preserve requester/capturer and ticket context. Reassignment requires a destination group, classification and internal comments in the UI, then updates the active workflow. Do not manually fabricate those variables or change a call's user IDs to make a queue look populated.

The authoritative modern ticket listing is HRF_SP_SERVICE_DESK_CALLS_MY_CALLS through HRFCLS_SD_CALLS.GetMyTickets. Native group/workflow visibility remains the functional contract. An empty assigned list may be correct for the signed-in user. First check scope and workflow state, then configuration; do not widen permissions as a troubleshooting shortcut.

4. Classify tickets and store documents

4.1. Native classifications

4.2. Document type and storage

Set ServiceDesk / ServiceDesk / Doc_Type_ID to an active DOC_DOCUMENT_TYPE record. The document helper resolves the library linked to that type and indexes the file before linking it to the ticket. The modern upload index contains CALL_ID, COMP_CODE and EMP_NO. The uploaded file is first written to the configured application cache with a generated file name; indexing requests deletion of that temporary source after upload. Storage can use the installed document library's local or Azure-backed source configuration. Do not put storage credentials into a guide or a support ticket.

4.3. Acceptance checks

1. Upload an approved small screenshot and PDF through each supported entry point. Confirm a ticket link, viewer result and intended library placement.
2. Test a disallowed extension and a batch that exceeds the intended request limit in a controlled acceptance environment. Record the actual result rather than claiming a limit based on UI text.
3. Test partial failure: retain the saved ticket reference and inspect which files linked successfully.
4. Confirm cache write permissions and library connectivity without exposing private paths or connection secrets in user-visible errors.
5. Test authorised document removal and verify that unrelated documents are unaffected.

5. Configure reusable solutions, FAQ and Knowledge

5.1. Common solutions are an explicit support action

Assistant / Chatbot2 / CommonSolutionsEnabled controls the modern common-solution endpoints. Missing or unrecognised values leave the service disabled. Enabled search uses HRF_SP_SD_COMMON_SOLUTION_SEARCH with at most five results; titles/problems/solutions/keywords are normalised to plain text. Saving uses HRF_SP_SD_COMMON_SOLUTION_SAVE; use recording is separate through HRF_SP_SD_COMMON_SOLUTION_USE. These are not equivalent to an automatic Knowledge Hub publication.

5.2. FAQ host and legacy content

The Support FAQ action calls the parent host's toggleFAQModal function. Test it from the standard My Focus host as well as any embedded context; opening HRFSupport.aspx alone does not create that host integration. Legacy capture can also load HRF_SERVICE_DESK_FAQs. MyFAQ.aspx uses the older FAQ-topic model, and MyFAQAdmin/MyFAQTopics are distinct legacy administration pages. Choose the intended content pipeline rather than assuming every FAQ screen uses the same table.

5.3. Knowledge audience and type rules

The modern Knowledge Hub uses HRF_KB_Items with active area, entry type and optional active category. KnowledgeScopePolicy permits static FAQ in FAQ and static KnowledgeArticle in Knowledge. MyData needs an authenticated employee context; dynamic execution is restricted to MyData/MyDataQuery. Unsupported or unknown area/type combinations are not execution permissions. A general support article must not gain employee-data SQL just because it is being published from analytics.

5.4. Version configuration and FAQ transfer

The setup "configure version" action executes HRF_SP_SERVICE_DESK_CONFIGURE_VERSION. This changes menu/instruction targets and can transfer old Service Desk FAQs into Knowledge. Treat transfer as a migration, with a backup, source/target counts and duplicate review. The inspected procedure's transfer duplicate predicate is not a safe rerun guarantee; repeated forced transfer can duplicate content. Do not use ForceTransfer as a routine refresh. Review and correct any migration issue through a separate approved implementation before production use.

The migration marker is SYSTEM / Configuration / KnowledgeItems.OldServiceDeskHowToImproted, using the installed spelling. The migration resolves FAQ area/type and General category. Validate those target lookup rows and editorial quality before activation. Version routing does not automatically replace every workflow approver page; inspect existing templates and instructions.

6. Configure Chatbot Analytics and editorial publishing

6.1. Access and supported authoring

ChatbotAnalyticsAccess.UserCanView requires a valid session/user, AnalyticsEnabled and an allow-listed user ID or exact group membership. UserCanAuthorKnowledge adds the authoring gate. UserCanGenerateAIDraft adds all three AI gates. The controller rechecks access on its endpoints and prevents caching of analytics responses. A general administrator title does not bypass the explicit allow list.

1. Allow the smallest intended editorial audience and verify one permitted and one unpermitted account.
2. Open HRFChatbotAnalytics.aspx. Confirm overview, date/source/rating/search filters, question detail and the Knowledge improvement history. The overview can return bounded lists, such as 50 top questions; the export is labelled Export loaded questions.
3. Enable authoring only for the intended editors. Lookups are limited to active FAQ/Knowledge areas, active categories and entry types FAQ or Knowledge Article.
4. Choose a question group, enter the required title/question/short answer and select a valid area/category/type. Save a draft first when editorial review is still outstanding.
5. Use an explicit Publish action only after checking the organisation's policy and removing case-specific or confidential content. Confirm the resulting Knowledge item and its active audience.

6.2. Optional AI draft boundary

The suggestion endpoint rejects unsuitable questions before sending them to Ask AI. Its instructions request general process guidance and prohibit invented policy, personal/payroll values, legal conclusions and confidential information. These controls do not guarantee correctness. An editor must still review the generated draft, verify organisation-specific wording and decide whether to save or publish. Disabling AI drafting does not remove the separate manual Knowledge-authoring route.

6.3. Database and API contracts

Read operations use HRF_SP_CHATBOT_ANALYTICS_GET and HRF_SP_CHATBOT_ANALYTICS_QUESTION_GET. Publishing uses HRF_SP_CHATBOT_KNOWLEDGE_ITEM_SAVE and records the question-group relationship, user and action. The API permits only entry types 1/2 and requires title, question and short answer. Character limits include title 300, question 500, short answer 1500, full content 8000, tags 1000 and editorial notes 1000. The controller builds safe Knowledge HTML from plain content.

7. Notifications and report-export preferences

7.1. Notifications follow actual workflow actions

The modern CreateTicket path persists the request and calls StartWorfklow. The initial configured destination determines creator/first-support notification actions through HRFCLS_NOTIFICATIONS_WRAPPER. On-behalf capture has separate capturing-user/target-user branches. Do not promise identical recipients for every case; test the selected template and actual memberships.

Inspect existing email templates, destination types, recipient addresses, queue processing and provider health. The wrapper supports user/group/role-style destinations in these paths; a pool-delivery TODO is not a tested delivery feature. A successful ticket save and a successful email delivery are separate outcomes. Never fix a delivery issue by placing credentials or unrestricted recipients in the ticket description.

7.2. Shared export defaults

Manage these values under Modules/HRF_REPPORTAL/ADMIN/HRF_REPPORTAL_ADMIN_REPORTS_SETTINGS.aspx in the Export defaults card, using the preferred-format dropdown and one-worksheet checkbox. Values are read on each fresh export-panel opening. The user can override layout/format for the current download. Where a preferred format is unavailable for a report, the helper selects Excel if permitted, otherwise the first permitted format. Support has only Excel and opens its own Export Support Tickets modal, using shared defaults/rendering rather than the full ReportSettingsUI panel.

Support Export runs a fresh authorised GetMyTickets query on the server and applies the current status, nested search/column filters, sorting and permitted visible columns to all matching pages. Its modal fixes Format to Excel (.xlsx). Unchecked one-worksheet preference produces Report Summary and Results; checked produces one Results worksheet with report/company branding, header, criteria and typed data. Test both layouts, row count, actual logo/branding, dates and values, and an empty authorised assigned scope. Do not equate export scope with every database ticket or only the current page.

8. Roll out, troubleshoot and retain evidence

8.1. A practical acceptance sequence

1. Before change: record the release, current setting keys/values, workflow mapping and existing menu/FAQ target routes in private change evidence.
2. Provision only missing settings. Preserve current and default values already selected by the organisation. Apply approved database scripts in their established release order.
3. Test employee create, required fields, selected category/subcategory, contact values and generated reference. Confirm that the expected workflow and permitted recipients are used.
4. Test update and attached-document viewing/removal, including partial upload failure and session expiry.
5. Test first-line assigned visibility, public/internal feedback, activity history, operational priority and second-line reassignment. Verify an unrelated user's scope.
6. Test on-behalf employee selection/preview and saved ownership. Test resolve/close/cancel once with an intended acceptance record; verify confirmation, notes, dates and notification effects.
7. Test optional common solutions and both authorised/unauthorised analytics/editorial paths. Verify draft versus publication and optional AI availability independently.
8. Test Support Excel and shared fresh-open export defaults, including a runtime override and existing client-setting preservation.
9. Collect final references, role/account labels, results and screenshots without sensitive values. Obtain operational acceptance and document rollback responsibility.

8.2. Operational boundaries

Do not disable triggers, bypass authentication, manufacture workflow assignments or edit employee ownership to make a test pass. Preserve existing cases and follow the approved rollback plan for configuration changes. Treat legacy FAQ transfer separately because menu routing and data migration are different kinds of change. Screenshots of editor states show available controls; they are not evidence that a save, notification or upload succeeded.

8.3. Implementation evidence map