1. Configuration map and release scope

This guide traces release 2026.10.1.0 to the current Web Forms frontend, API controllers and explicit tool services. It describes configuration and validation; it does not enable features, change permissions or execute deployment. Installed clients can have different setting values and business sources.

Use the settings register for exact keys, runtime fallback values, deployment initial/default values and inspected script references. A code fallback is not the installed value. Some seeds use an initial value of 1 while storing a default of 0. Do not infer rollout from a screenshot or the default column alone.

2. Settings and controlled rollout

Most preferences use HRF_MYFOCUS_SETTING, module Assistant, category Chatbot2. External dependencies are explicitly identified. The MyFocus Settings page saves through the established handle and updates the in-process settings collection. A direct SQL change may require the application’s established refresh or recycle process before every worker sees it. Test a fresh assistant bootstrap after a permitted change.

1. Record current and default values and relevant permissions before changing settings.
2. Confirm approved deployment sequence and dependencies. Do not run a whole release folder merely to enable a switch.
3. Pilot reviewed sources and read-only tools with representative roles.
4. Enable external services only after credential, outbound-connectivity and organisational review. Keep the Direct Line key out of browser code, screenshots and public documentation.
5. Refresh configuration through the established process. Check a fresh bootstrap, a positive role and a negative role.

The Logon system-settings control stores Assistant/General/ChatBotDirectLineKey. Chatbot2 preferences are read by their exact triplets; use the generic MyFocus Settings editor unless the installed client provides a dedicated screen. Frontend visibility is not a substitute for server gates.

3. Knowledge and fallback boundaries

Grounded lookup searches configured Knowledge, suggestions and common solutions. The controller returns at most five Knowledge results. Dynamic My Information execution is bounded to three matching items, eight rows and twelve columns, using signed-in employee/user context. KnowledgeScopePolicy checks supported area/type pairs and active item, area, type and category metadata.

HRFKnowledge.aspx is the normal Knowledge handoff. HRFAgents.aspx exposes the configured agent catalogue. Navigation suggestions derive from authorised menu routes; a returned title does not manufacture access.

Ask AI requires Assistant/Chatbot2/AskAIEnabled plus System/WebApi/OpenAIEnabled. Automatic AI fallback is a separate preference. Bot Framework fallback obtains a token on the server using the configured Direct Line key. Intent screening or unavailable navigation can prevent fallback. None of these settings certifies generated answers or enables unrestricted natural-language database querying.

4. Dashboard eligibility and card filters

DashboardVisualsEnabled is disabled by default in its provisioning script. Discovery uses accessible portal/dashboard metadata and rechecks the selected definition, source-query eligibility and supported controls. DashboardVisualsAllowedElementGuids explicitly exposes stable elements for supported inline projection. It grants no portal permission and is not a blanket native-widget exposure list.

ChatbotPortalFilters prepares card-owned criteria from current metadata. Standard controls can include dates, reporting levels and departments where supported, plus configured dynamic options. A protected context binds user/session, element and definition/filter hashes. Execute requires prepared criteria to match. Handle invalid options, expiry and definition changes by reselecting the visual.

1. Choose a permitted visual and compare its chat title with the source dashboard.
2. Inspect default criteria, change supported controls and apply filters.
3. Open a second card and the source dashboard; confirm neither selection was replaced by the first card.
4. Refresh and exercise a changed-definition or revoked-access case with an authorised test account.
5. Check categories, every series, all table columns and data-view values before cleared captures. Chart-type changes can retain cached values; changing labels alone does not clear private data.

The native scope binds one verified query to one card through HttpContext.Items and restores the previous scope on disposal. It does not overwrite normal dashboard selection/parameter session. Component options, chart/data views, refinement and exports depend on the selected control. Unsupported advanced filtering stays in the source dashboard.

Line uses Description with Value and Value2. A returned data table may also include Completion_percent. Available native component options depend on its source control.

5. Personal tools, team scope and documents

ChatbotWorkspaceService dispatches a fixed read-only list: team-contact, team-milestones, org-chart, daily-actions, request-tracking, learning, leave-planning, recruitment and hr-followup. It accepts bounded text and employee selection, then delegates to module-specific services. It accepts no generated SQL or client-supplied manager/company scope.

Sensitive personal, document and dashboard history restores metadata and requires a current refresh. Conversation history uses browser session storage keyed to the user; it is separate from centrally recorded analytics. This preference is not a global retention or deletion policy.

Normal document/PDF access, employee verification and original module permissions remain outside chat settings. Validate them through existing administration rather than weakening access to make a card visible.

6. Reports, builder drafts and leave handoff

Report search uses the user’s accessible catalogue. Preview is bounded and can require the normal viewer when parameters or a source are unsupported. ReportingEnabled is the parent gate; ReportPreviewsEnabled and ConversationalReportBuilderEnabled separately control extensions. Runtime bounds: ReportSearchLimit 6 (1–12), ReportPreviewMaxRows 12 (1–50), ReportPreviewMaxColumns 8 (1–16), ReportDraftMaxFields 6 (2–8).

A report draft is stored in the user session with a random token and a 30-minute maximum age. Opening the visual Report Builder hands off a proposal for review. Returning a draft does not save a report. Preserve source permissions and normal builder validation.

Guided leave collects a bounded draft with type, dates, reason, validation preview and document refresh. Handoff changes draft status to HANDED_OFF and returns a secure request URL. Final leave submission still runs on the normal screen, with calculated values, required documents and existing workflow.

7. Support, attachments and recorded evidence

ServiceDeskHandoffEnabled controls optional ticket endpoints. ServiceDesk/General/Version determines the source route. SupportAttachmentsEnabled and chat count/size settings govern the offered attachment experience: SupportMaxAttachments fallback 5, bounded 1–10; SupportMaxAttachmentMB fallback 10, bounded 1–25. Native document-type/library and upload-server limits still apply.

Ticket creation is a business write. The user must deliberately review subject, question, category and attachments before submitting. This guide performs no write. Existing Service Desk assignment, messages and workflow retain their normal implementation.

Interaction, outcome, event and feedback endpoints record supported analytics evidence through installed Chatbot procedures. FeedbackTextLoggingEnabled can suppress stored feedback comments; it does not globally disable question/event logging. Define authorised access, retention and incident response separately. Keep credentials, tokens and real private conversation payloads out of launch material.

8. Analytics and human-reviewed publishing

Open HRFChatbotAnalytics.aspx through the authorised route. AnalyticsEnabled must be enabled and the current user must match AnalyticsAccessUserIds or an exact group in AnalyticsAccessGroups. Lists accept comma, semicolon or pipe separators. Empty access lists do not grant everyone access. AnalyticsDefaultDays fallback 30 is bounded 1–365.

1. Choose the period and available user, answer-source, rating or search filters. Refresh and read counts as recorded interactions, not proven resolutions.
2. Review grouped questions, gaps, feedback and question detail. Distinguish a source gap from access, wording or disabled-tool problems.
3. Open the eligible Knowledge editor. Choose FAQ or Knowledge Article and valid active area/category.
4. Write a draft or request optional AI help only when permitted. Confirm the policy/process with its owner and remove personal details.
5. Save a draft or explicitly publish after review. Re-query as the intended audience, including a negative-access case. Record success only for an authorised completed save.

AnalyticsKnowledgeAuthoringEnabled gates writes. AI drafting additionally requires AnalyticsAIDraftEnabled, AskAIEnabled and System/WebApi/OpenAIEnabled. Each controller action rechecks access. Save permits entry types 1/2, requires title/question/short answer and bounds title 300, question 500, short answer 1500, long answer 8000 and notes/tags 1000 characters. HRF_SP_CHATBOT_KNOWLEDGE_ITEM_SAVE performs the explicit requested draft/publish operation.

AI wording does not validate policy. Editorial work requires an owner, review cadence and a rollback process. Do not promise automatic FAQ generation or answer correctness.

9. Deployment and targeted verification

Reconcile the installed package before running scripts. Current standard components are grouped under DB/HR/0.STANDARD/003. BO/13. Chatbot 2.0 (Intelligence, Reporting, My Information Catalogue, Documents and Personal Dashboard). Dashboard switches/verification also appear under 003. BO/06. Agents. Analytics portal wiring can appear under 26. HR Analytics. Register references identify inspected files; they do not instruct execution of every release file.

1. Record settings/permissions and use the approved backup and deployment process. Confirm frontend/API assemblies and database objects match the release.
2. Review SQL ordering and existing-value behavior. Intelligence settings can fill blank values and update default/editor metadata; that script is not universally insert-only. Dashboard visual script 905 preserves existing values.
3. Run targeted deployment checks, signed-out rejection and positive/negative role cases.
4. Check Knowledge visibility, own-data context, team selection, document verification, report limits and a source-only dashboard case.
5. Exercise card filters/refresh, history restore, light/dark and mobile. Compare chart/Data values and clear all represented data stores before captures.
6. Perform business-write QA separately for tickets, leave and Knowledge publication; record actual persisted results.

10. Troubleshooting and maintenance

Maintain reviewed Knowledge owners and source links, measure actual feedback trends and preserve older documentation editions. Recheck settings and access after release or role changes. The companion user guide covers operational tasks; the employee adoption pack intentionally excludes administrator internals.