Skip to main content

    1068 Ideas

    priya.kornalius
    priya.kornaliusKnown Participant

    Interception is not passing the recommended KB links in ticket comment1. New

    We're experiencing several interception issues with the Copilot version of the bot, which has made the experience increasingly frustrating for the team. I’m documenting one such issue below for the product team to evaluate as a potential improvement opportunity.In the classic version, when the bot intercepted a ticket, it posted its full response along with the referenced KB article links directly in the ticket comments. This was extremely helpful, as it allowed us to:See which KBs were recommended to the user Track the bot’s response accuracy Take corrective actions by updating or improving the KBs based on user feedbackHowever, in the Copilot version, the bot only adds the answer summary in the ticket comment without any reference to the underlying KB sources. Since the bot is summarizing content from the top-ranked results, we have no visibility into which KBs were used to generate the response. This lack of transparency makes it difficult to validate or improve content quality.Moreover, we can’t depend on end users to manually share this information from their chat platforms each time—it’s neither scalable nor reliable.We’ve lost many of the valuable capabilities that the classic bot used to support, and this is affecting our ability to govern and improve content effectively.SuggestionInclude the source KB links or identifiers along with the bot’s response in the ticket comments, just as it worked in the classic version. This will improve traceability, content governance, and user trust in the system. 

    afleury
    afleuryInspiring

    Ticket Nudge - Structured “Still an Issue” Follow‑Up1. New

    Challenge• When Moveworks sends a ticket nudge (“Is this still an issue?”), users often reply yes with no context.• Analysts then lack actionable detail and must ask further questions, creating unnecessary back‑and‑forth.• The platform currently does not support enforcing or encouraging a structured explanation when a user indicates the issue persists. Proposed EnhancementAdd an optional “Reason Required” mode to the ticket‑nudge workflow.When a user selects “Yes, it’s still an issue”, Moveworks prompts the user with a structured follow‑up question such as:• “What’s not working? Please be specific.”• “What changed or what are you seeing now?”• “Add any new symptoms, screenshots, or error messages.”This could be implemented via:• A configurable follow‑up template in Moveworks.• A conditional “required field” before the bot updates the ticket state.• A lightweight form or message collector to capture context.Value• Reduces the ping‑pong between bot → user → analyst.• Improves ticket quality and accelerates resolution.• Ensures Moveworks captures meaningful data at the point of user friction.• Increases analyst trust in bot‑driven follow‑ups.Note: I’ve discussed this with the Moveworks Support team, they advised this functionality is not possible yet and to raise a feature request hence this request.

    Selective Log Redaction Overrides for Specific Payloads and Fields4. Future Consideration

    SummaryMoveworks currently applies global log‑redaction rules that often remove sensitive data from all payloads uniformly. While this protects customer information, it can make troubleshooting, debugging, and rule development extremely difficult when certain payloads must be visible temporarily or permanently.This request proposes a controlled mechanism to disable or override log redaction for specific payloads and specific key/value fields, using an extension to the existing redaction DSL. Problem StatementToday, log redaction is fairly extreme, and not easily refined at the project level (that I can tell)Redaction is applied globally Redaction cannot be disabled for specific data objects Redaction cannot selectively reveal individual fields Debugging issues in pipelines, transformations, audits and DSL logic becomes challenging without visibility into certain parts of the payloadAs a result, teams often struggle to analyze issues effectively without temporarily weakening overall log safety.Proposed Solution: Redaction Override ruleExtend the existing Moveworks redaction rule to support a new structure that allows per‑payload and per‑field exceptions.{ "show": { "info": [ "data.anotherPayload.Name.First" ], "debug": [ "data.myPayload" ] }, "redact": [ "data.sensitive", "data.userPayload.user_choice" ]}How it would work show list Any paths listed under "show" are preserved in full. Full objects (e.g., data.myPayload) can be whitelisted. Individual fields (e.g., .Name.First) can also be whitelisted. show info/debug  Info or Debug settings mean that item will log in production mode or debug mode. For logging info mode there would be a simple log entry that shows just that payload, this might be similar to accessed_variables in the logs. redact list Specific objects or fields can still be forcibly redacted even if part of a visible payload. Final redaction behavior Redaction system evaluates "show" rules first (explicit allowlist). "redact" takes precedence for any subfields explicitly listed. Any data not mentioned falls back to existing platform defaults. at the kick off a plugin - the redaction rule would show in the logs on the info entry. BenefitsFor DevelopersCan fully inspect problematic payloads during debugging Reduces friction and time to resolution No need to disable global redaction settingsFor Security & ComplianceOverrides are explicit, documented, and controlled Redaction remains applied everywhere except where explicitly allowed Still enables field-level protection for sensitive subfield dataFor Platform ConsistencyBuilds on the existing redaction DSL Maintains an opt‑in model rather than broad “disable redaction” switches Minimizes implementation complexity while maximizing flexibility