Skip to main content

    Filter by idea status

    Filter by product

    1344 Ideas

    vinitbKnown Participant

    Configurable Cooldown Window for Webhook-Triggered Plugins/Notifications (Ambient Agents)1. New

    SummaryWe're building ambient agents that send notifications via webhooks from device monitoring tools (Zscaler, Tanium, Aternity). Since these tools re-fire alerts continuously while an issue persists, users get flooded with duplicate notifications for the same issue.We need a configurable Cooldown Feature — either new or an extension of the existing 1-hour de-duplication logic — that suppresses repeat notifications per user/issue over longer windows (7–15+ days), without requiring an external database.The ProblemWebhook storms: Monitoring tools fire repeatedly as long as a condition holds — they have no awareness of whether a user was already notified. De-dup window too short: Moveworks' current de-duplication caps out at 1 hour, but many device issues take days to resolve, causing repeated alerts. Costly workaround: Without native support, we have to build/maintain an external database just to track notification state and gate webhooks before they reach Moveworks — adding latency, complexity, and ongoing maintenance.Proposed SolutionLet devs/admins set a custom cooldown duration on webhook-triggered plugins natively in Moveworks. On each incoming webhook, a Cooldown Engine checks whether the target user already got a notification for that issue within the window:If yes → suppress the notification. If no → send it and reset the cooldown timer.Key RequirementsCustom cooldown windows — admin-configurable per plugin (hours or days, supporting 15+ days). Flexible uniqueness keys — cooldown logic based on combinations like User ID + Issue/Alert ID, or Plugin ID.Business ValueBetter UX: Cuts notification fatigue, reduces risk of users muting/ignoring the bot. Faster time-to-value: Enables proactive IT use cases out-of-the-box, no external middleware needed. Lower overhead: Keeps the entire logic loop native to Moveworks, reducing architecture and API costs. Note: This request seems related to the below 2 requests about notifications management. But I created a separate request because the other 2 are talking about USER preferences, while we are looking for developers to be able to set this cool down duration:End User Notification controls in Copilot | CommunityUser Preference & Notification Management Framework | Community

    KellyMVCommunity Manager

    Productivity Assistant Builder2. On Roadmap

    How are we improving the product?Work does not stop at finding information, completing a standard workflow, or filing a ticket. Many of the most valuable tasks employees perform are contextual and nuanced: preparing for an important customer meeting, analyzing candidates, writing a performance review, researching a market, coordinating a complex project, or producing an executive-ready deliverable.Productivity Assistants are purpose-built AI assistants designed to excel at work like this. An assistant can be tailored to a particular task, role, team, or business domain—with focused knowledge, tools, instructions, and access—so it understands the context of the work and helps drive it toward a useful outcome.Employees and administrators will be able to create Productivity Assistants without code, start from approved templates, or adopt prebuilt assistants for common use cases. Examples may include calendar management, recruiting coordination, customer preparation, RFP responses, onboarding, performance reviews, research, and team operations.What can Productivity Assistants do?Depending on how they are configured, Productivity Assistants can:Long-Running Tasks: Complete complex work that requires multiple stages of research, analysis, planning, and execution—such as deep research, account preparation, or creating a comprehensive report.Contextual Behavior: Focus on selected enterprise or external sources, follow task-specific instructions, and apply the right context for a particular role, team, domain, or workflow.Skills: Use reusable skill packages—including SKILL.md instructions and supporting resources—to consistently perform specialized tasks according to an organization’s preferred methods and standards.Enterprise Knowledge and Web Research: Search, compare, and synthesize information across selected company sources and current public information, with citations back to the supporting material.Tools and Actions: Use approved plugins, integrations, and enterprise tools to retrieve information, update records, initiate workflows, and take authorized action across connected systems.Artifact Generation: Turn completed work into polished, shareable outputs—including interactive experiences, reports, presentations, documents, PDFs, tables, charts, dashboards, and prototypes.Conversational Refinement: Let employees review an answer or artifact, request changes, explore details, and continue iterating without restarting the work in another application.No-Code Creation: Create an assistant from scratch or customize a template by selecting its purpose, instructions, knowledge, tools, skills, conversation starters, and intended audience—without writing code.Prebuilt Assistants and Templates: Start quickly with vetted assistants and reusable templates designed for common roles and use cases, then tailor them to the organization’s needs.Governance and Sharing: Share assistants with the appropriate individuals, teams, roles, or groups while giving administrators control over who can create, configure, publish, and broadly distribute them.Permissions-Aware Operation: Respect existing enterprise permissions so employees only access information and perform actions they are already authorized to use.Cross-Channel Access: Use Productivity Assistants through EmployeeWorks web and supported enterprise messaging experiences, allowing employees to access focused assistance where they work.Availability and rolloutCapabilities may be introduced in phases. The assistants, knowledge sources, tools, skills, artifact formats, channels, sharing options, and administrative controls available during controlled availability may differ from the complete planned experience.Licensing and documentationLicensing, packaging, configuration guidance, and getting-started documentation will be shared before broader availability.

    afleury
    afleuryInspiring

    Dedicated Notifications Tab for Moveworks in Microsoft Teams (and Slack)1. New

    The ProblemToday, the Moveworks bot in Microsoft Teams (and Slack) only has a Chat and Shared tab. All notifications — ticket updates, approval requests, pending actions, comms — land directly in the Chat conversation alongside regular bot interactions.This creates a real problem:Notifications get buried. As soon as a user sends a new message to the bot, older notifications scroll out of view. There's no way to see a consolidated list of pending items without scrolling back through the chat history. Busy managers lose track of approvals. Managers with high approval volumes can't efficiently triage what needs attention. They're not going to have a back-and-forth conversation with a chatbot to filter down pending requests — they'll just open ServiceNow directly, which defeats the purpose of the bot. The problem gets worse at scale. The more notification types you enable (ticket concierge, approval reminders, comms, visitor alerts), the noisier the chat becomes, and the more likely critical notifications are missed.As one of our store managers put it when testing Bolt visitor notifications:" it kind of got lost between two others, so not necessarily obvious." What We WantWe'd love Moveworks to adopt the same tab structure that other Teams apps (like Workday) already use:Tab Purpose App Dedicated notification feed — ticket updates, approval requests, pending actions, comms. Structured, scannable, persistent. Chat Conversational interaction with the bot — questions, lookups, form submissions. Shared Shared files and links (already exists). The Workday Teams app is a great reference. Its "App" tab shows Quick Actions, tasks, and calendar events — completely separate from the "Chat" tab where users interact with the Workday bot. Notifications like time-off approvals appear in Chat, but the persistent task list lives in App. This separation keeps things clean and actionable.Why This MattersYou've already solved this on the web. The Moveworks Web Assistant (/assistant) has a dedicated Notifications panel — separate from the chat. It works well. But it pulls users away from their primary collaboration platform (Teams/Slack) and requires additional SSO app assignment (e.g. Okta), which is more admin overhead.  Microsoft Teams supports this pattern natively. The Teams platform provides Activity Feed Notification APIs and supports custom tabs within bot apps. The technical capability exists.  Meet users where they are. Moveworks' own mission is to "meet employees where they are." For most enterprises, that's Teams or Slack — not a separate web portal. The notification experience should live there too.  Approval velocity. Managers need a glanceable, structured view of what's pending — not a chat transcript to scroll through. A dedicated tab would significantly reduce approval turnaround time and friction.What This Could Look LikeNotification feed in the "App" tab — filterable by type (approvals, ticket updates, comms, reminders). Badge count on the App tab showing unread/pending notifications. Actionable cards — approve/reject, acknowledge, or deep-link to ServiceNow directly from the notification. Persistent state — notifications remain visible and accessible until actioned, not buried by new chat messages.Who This ImpactsThis isn't a niche request. Every Moveworks customer on Teams or Slack that uses ticket notifications, approval workflows, or employee comms is affected. The challenge scales with org size — the more users and notification types you enable, the worse the chat-noise problem becomes.TL;DRCurrent State Desired State All notifications land in the Chat tab Notifications in a dedicated App tab Notifications scroll away with new messages Persistent, scannable notification feed Managers must scroll or ask the bot to filter Structured view with filters and badge counts Web Assistant has this — Teams/Slack doesn't Parity across all surfaces Web Assistant requires separate SSO/Okta app Keep the experience in Teams/Slack If you're dealing with this same challenge — please upvote and comment. The more visibility this gets, the more likely it makes it onto the roadmap. 🙏Here’s what it could look like 

    HTTP Action - Response Schema is unintentionally overwritten by Test/Publish, with inconsistent behavior1. New

    Context:In the HTTP Action config,  the Response Schema starts as an open/accept-all schema ({}). Running Test replaces this schema with whatever payload shape came back from that specific test call. If the user then hits Publish, that test-derived schema overwrites the previous (intentional) schema — with no confirmation or way to prevent it.Problems:No way to save/apply a schema independently of Publish There's currently no dedicated "Save Schema" or "Apply Schema" action. The only way a schema gets set is as a side effect of running Test, which is not obvious and easy to trigger by accident. Publish silently overwrites the schema after a Test run If a user runs Test (even just to check something) and then hits Publish, the schema from that one test call replaces whatever schema was previously defined — even if that test payload wasn't meant to become the new schema. Since different test calls can return slightly different payload shapes, this makes it very easy to unintentionally wipe out a correct, working schema with an incomplete or one-off version. Inconsistent schema behavior across repeated tests Even with a schema already defined in the Response Schema section, results are inconsistent. Running the same test multiple times — with zero changes to the HTTP action or any republishing in between — sometimes returns the expected payload, and sometimes returns a null/empty response instead when ran from a conversational process for example. Requested fix:Decouple schema updates from both Test and Publish — schema should only change when a user explicitly chooses to save/apply it or possibly links a data type to it. Add a clear "Save Schema" or "Apply Schema" action so users control when the schema is updated, rather than it happening automatically as a side effect of testing. Investigate the inconsistent null-response behavior on repeated test calls with no config changes — this points to something unstable outside of user action, not just a UI/schema issue.

    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.