Skip to main content

    Filter by idea status

    Filter by product

    1123 Ideas

    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

    taylorkf15Known Participant

    EXI: Adding Topics from Employee Issues Map to Apps & Services Detail4. Future Consideration

    Hello! I would like to put in a request for the following in EXI:In the “Employee Issues” dashboard, you can download CSV files of the tickets that are categorized in each of the 24 tiles on the employee issues heat map. The extremely beneficial information from these CSV files is the Topics column (that are determined via AI by reading the short description of the help desk ticket). The topics allow us to easily extract the main issues people are having/submitting help desk tickets for, and thus allow us to pinpoint the top issues.  The biggest downfall is that we need to manually download all 24 CSV files and combine into one file, which is time consuming. THE REQUEST: Add the ability to download a CSV file with all tickets that contain the Topic column (and the category type e.g., “Troubleshoot Information”; the same information that can currently be downloaded now for each of the tiles on the heat map). BUG: In the “Apps and Services Detail” dashboard, you can download one CSV file for all tickets, but there the information in the “Topic” column and TTR when you download the file is wrong. If this is fixed, this may solve the issue, but it would be ideal to be able to include the ability to download a file of all tickets within the given timeframe on both the “Employee Issues” and and “Apps and Services” Detail dashboards that includes a column with the topics.