Skip to main content

    Filter by idea status

    Filter by product

    1293 Ideas

    afleury
    afleuryInspiring

    Allow Policy Enforcement and Validation for Distribution List Provisioning1. New

    SummaryMany organisations use self-service provisioning to create distribution lists, groups, and collaboration resources. While access controls determine who can request these resources, there is often no way to enforce organisational standards during the provisioning process itself.ProblemToday, administrators can control who is allowed to create resources, but they cannot define and enforce policies that govern what is created.Common requirements include:Naming convention enforcement Approved domain validation Pattern or format validation Resource classification requirements Automatic standardisation of user input Custom business rules based on organisational needsWithout policy enforcement, organisations must rely on user training, manual reviews, or post-creation remediation to maintain standards.Proposed EnhancementIntroduce a policy validation framework that is evaluated as part of the provisioning workflow.Administrators should be able to:Validate user input before resource creation Define required naming standards Restrict values to approved formats or domains Apply automatic transformations where appropriate Display clear validation messages when requirements are not met Configure different policies for different resource typesExample Use CasesEnforcing naming standards for distribution lists Restricting email domains to approved corporate domains Requiring specific prefixes or suffixes Enforcing department or region identifiers Standardising display names and aliases Validating group ownership requirements before creationBenefitsImproved governance Consistent resource naming and structure Reduced administrative overhead Better compliance with organisational standards Fewer provisioning errors Better end-user experience through immediate feedbackWhy This MattersSelf-service provisioning is most effective when organisations can trust that resources created through automation comply with their internal standards. Access control answers who can create a resource, while policy validation answers whether the resource itself meets organisational requirements. Both capabilities are needed for scalable governance.Voting ask: If your organisation uses self-service provisioning and has naming, compliance, governance, or standardisation requirements, please upvote this idea to help prioritise policy enforcement capabilities within provisioning workflows. PS: I’ve already tried Moveworks/ServiceNow Support and Engineering teams advised to raise a Product idea.

    ramapr1New Participant

    Improve translation and label clarity for request submission and help options1. New

    There are two areas causing confusion for employees interacting with Moveworks bot in Japanese language.First, the button label currently used across forms - “Complete this request”, is being interpreted too literally. In Japanese, the wording gives the impression that the action will finalize or close a process, rather than simply submit information for a question or request. Users feel this creates the wrong expectation and may discourage users from submitting their HR case request. A more neutral term, such as “Make” or another phrase that clearly indicates submission or creation, would better reflect the intended action.Second, the Get Help link is causing confusion because the Japanese translation appears as Support Request. Users see Get Help referenced in Moveworks bot, but they cannot find that exact option because the translated label is different. This becomes even more confusing when Moveworks bot explains that support request is not the same as Get Help. As a result, users are left unsure which option they should choose.We understand that Get Help is part of Moveworks out of box functionality. We would like to ask if there is any appetite to review or update this terminology for better clarity.In addition, request to make the wording "Complete this request" customizable.Requested outcome: We would appreciate Moveworks reviewing these terms from a localization and usability perspective so the labels are easier to understand for Japanese users and reduce confusion during request submission and help navigation.

    nicole.hulst
    nicole.hulstKnown Participant

    Multiple Triage Models and integration of Triage with Agents from Agent Studio1. New

    We were having high hopes and expectations for Triage 2.0 to help us in reducing manual routing efforts to an absolute minimum. What we have found that Triage works exceptionally well in highly specialized cases where we have a high ticket volume. But this is not scalable. We can either have really good Triage for one Service or really crappy Triage for all our Services. What we obviously want is good to really good Triage for all Services to actually reduce our workload instead of just shifting it to second or third level support. The good results of the specialized models need to be scalable for enterprise wide useTo solve this issue what we require is the possibility to define multiple Models or Indices that run for different groups of Tickets. Ideally we could even have multiple Triage Runs on the same tickets. I envision something like: General Triage runs through all incoming tickets and identifies based on the description the right Service and routes to the respective Service Offering Depending on the Service Offering selected a new model is triggered for Triage for that specific Service and potentially take into consideration more fields than just description to route to the accurate second level group. Meaning we would have multiple models for the different services all specialized in the specifics of each service On a second Triage run also outside information should be taken into consideration such as work instructions for SD Agents that already contain explanations on routing accurately etc. Lastly if Triage cannot identify any further routing but the Ticket still needs automated actions we want to be able to trigger AI Agents to work on the ticket, but that trigger should come from Triage so there is no interference.  

    nicole.hulst
    nicole.hulstKnown Participant

    Multiple Triage Models and integration of Triage with Agents from Agent Studio1. New

    We were having high hopes and expectations for Triage 2.0 to help us in reducing manual routing efforts to an absolute minimum. What we have found that Triage works exceptionally well in highly specialized cases where we have a high ticket volume. But this is not scalable. We can either have really good Triage for one Service or really crappy Triage for all our Services. What we obviously want is good to really good Triage for all Services to actually reduce our workload instead of just shifting it to second or third level support. The good results of the specialized models need to be scalable for enterprise wide useTo solve this issue what we require is the possibility to define multiple Models or Indices that run for different groups of Tickets. Ideally we could even have multiple Triage Runs on the same tickets. I envision something like: General Triage runs through all incoming tickets and identifies based on the description the right Service and routes to the respective Service Offering Depending on the Service Offering selected a new model is triggered for Triage for that specific Service and potentially take into consideration more fields than just description to route to the accurate second level group. Meaning we would have multiple models for the different services all specialized in the specifics of each service On a second Triage run also outside information should be taken into consideration such as work instructions for SD Agents that already contain explanations on routing accurately etc. Lastly if Triage cannot identify any further routing but the Ticket still needs automated actions we want to be able to trigger AI Agents to work on the ticket, but that trigger should come from Triage so there is no interference.