Skip to main content

    Filter by idea status

    Filter by product

    1293 Ideas

    ToolSmith7.0 Duplicate

    How are we improving the product?Building enterprise automations still requires significant manual work. Developers must translate a business need into Agent Studio building blocks, research APIs, configure authentication, map data, wire dependencies, and test the result.ToolSmith changes the job from assembling everything by hand to directing and reviewing the build. Describe the outcome you want in plain language, review ToolSmith’s proposed plan, and approve it before ToolSmith creates or updates anything.ToolSmith can help developers build new plugins, edit existing plugins, and debug failing plugins—all through a guided conversation in Agent Studio.How does it work?Describe the outcome. Start with the business result, intended users, required inputs, and what success should look like.Research and reuse. ToolSmith examines relevant documentation and the assets available in your organization. It reuses existing assets when possible and asks before changing them.Review and steer the plan. ToolSmith proposes an implementation plan that you can revise in normal language. Nothing is built until you explicitly approve it.Build with visible progress. ToolSmith executes the approved work in dependency order and reports progress and operation results in the conversation.Configure credentials securely. When a connector needs credentials, ToolSmith presents a secure configuration card. Credentials are not pasted into chat or stored in the ToolSmith conversation.Test and refine. Test the result, describe changes conversationally, and let ToolSmith update the relevant assets.Resume later. Your conversation preserves its plan, results, and pending credential requests so you can leave and return.What can ToolSmith work with during controlled availability?ToolSmith supports create, read, and update workflows for:HTTP, Script, and Compound ActionsConnectors, including HTTP and MCP connectorsPluginsConversational ProcessesData TypesStatic and Dynamic ResolversListenersToolSmith can also open an existing plugin so you can describe a change in plain language, review the proposed edits, and test the updated plugin in the same session. If a plugin is failing, you can point ToolSmith at the issue so it can investigate the root cause and propose a fix.Licensing informationLicensing information will be made available closer to controlled availability.Technical restrictions and known limitationsToolSmith cannot delete assets during controlled availability. This guardrail helps prevent accidental removal of a developer’s work.ToolSmith’s speed and accuracy vary depending on the third-party systems and APIs involved.ToolSmith performs best when a plugin involves no more than two third-party systems. More complex, cross-system workflows may take longer or require more developer guidance.ToolSmith conversations cannot currently be shared with other users.Builders should review and test all created or updated assets in a non-production environment before publishing them.Interested in ToolSmith?Upvote this product idea and leave a comment describing what you want to build, edit, or debug with ToolSmith.

    sidvermaCommunity Manager

    ToolSmith2. On Roadmap

    How are we improving the product?Building enterprise automations still requires significant manual work. Developers must translate a business need into Agent Studio building blocks, research APIs, configure authentication, map data, wire dependencies, and test the result.ToolSmith changes the job from assembling everything by hand to directing and reviewing the build. Describe the outcome you want in plain language, review ToolSmith’s proposed plan, and approve it before ToolSmith creates or updates anything.ToolSmith can help developers build new plugins, edit existing plugins, and debug failing plugins—all through a guided conversation in Agent Studio.How does it work?Describe the outcome. Start with the business result, intended users, required inputs, and what success should look like.Research and reuse. ToolSmith examines relevant documentation and the assets available in your organization. It reuses existing assets when possible and asks before changing them.Review and steer the plan. ToolSmith proposes an implementation plan that you can revise in normal language. Nothing is built until you explicitly approve it.Build with visible progress. ToolSmith executes the approved work in dependency order and reports progress and operation results in the conversation.Configure credentials securely. When a connector needs credentials, ToolSmith presents a secure configuration card. Credentials are not pasted into chat or stored in the ToolSmith conversation.Test and refine. Test the result, describe changes conversationally, and let ToolSmith update the relevant assets.Resume later. Your conversation preserves its plan, results, and pending credential requests so you can leave and return.What can ToolSmith work with during controlled availability?ToolSmith supports create, read, and update workflows for:HTTP, Script, and Compound ActionsConnectors, including HTTP and MCP connectorsPluginsConversational ProcessesData TypesStatic and Dynamic ResolversListenersToolSmith can also open an existing plugin so you can describe a change in plain language, review the proposed edits, and test the updated plugin in the same session. If a plugin is failing, you can point ToolSmith at the issue so it can investigate the root cause and propose a fix.Licensing informationLicensing information will be made available closer to controlled availability.Technical restrictions and known limitationsToolSmith cannot delete assets during controlled availability. This guardrail helps prevent accidental removal of a developer’s work.ToolSmith’s speed and accuracy vary depending on the third-party systems and APIs involved.ToolSmith performs best when a plugin involves no more than two third-party systems. More complex, cross-system workflows may take longer or require more developer guidance.ToolSmith conversations cannot currently be shared with other users.Builders should review and test all created or updated assets in a non-production environment before publishing them.Interested in ToolSmith?Upvote this product idea and leave a comment describing what you want to build, edit, or debug with ToolSmith.

    colemanCommunity Manager

    User consent authentication for on-premises systems2. On Roadmap

    What are we improving?Employees can use Moveworks with internal applications that require individual user authorization, even when those applications and identity providers are only accessible from within the company network.User consent authentication lets each employee connect their account and allows Agent Studio integrations to act with that employee’s existing permissions. This extends delegated authentication to private, on-premises systems without requiring customers to open an inbound connection to their network.How does it work?The experience starts with a familiar Connect action. The employee signs in to the organization’s identity provider and grants consent. Moveworks then uses the employee’s authorized access when the integration calls the internal application.Requests that must reach the private application or identity provider are routed through the existing Moveworks on-premises agent. The agent maintains an outbound connection to Moveworks, makes the request from inside the customer network, and returns the response through the same protected channel.The main authorization flows use this route:Exchanging the employee’s one-time authorization code for access tokensCalling the internal application with the employee’s authorizationRefreshing access when a token expiresRevoking access when the employee disconnects the integrationThe initial browser authorization remains direct because the employee’s browser is already connected to the corporate network or VPN.How is authentication data protected?OAuth client secrets stay in the on-premises agent configuration and do not leave the customer network. User tokens are encrypted by the agent before leaving the network and are decrypted only by the agent when they are needed for an authorized internal request.Moveworks stores and forwards the agent-encrypted values without access to their plaintext contents. Existing encryption at rest provides an additional layer of protection while the tokens are stored.What does this unlock?Organizations can build Agent Studio integrations that combine user-level authorization with systems that cannot be reached from the public internet. Employees keep the permissions already defined by the internal application rather than relying on a shared service account.Examples include internal calendar, productivity, IT, finance, and business applications that support OAuth 2.0 but are accessible only from the corporate network.What is required?A supported Moveworks on-premises agent must be deployed and connected.The internal application and identity provider must support a compatible OAuth 2.0 authorization-code flow.The integration must be configured to route the applicable authentication and API requests through the on-premises agent.Employees must be connected to the corporate network or VPN when the initial authorization page is available only internally.Customer administrators must configure the required service and OAuth client information in the agent.Are there technical considerations?The first authorization step relies on the employee’s browser being able to reach the internal identity provider. Organizations with multiple agent instances must configure them consistently so authentication requests can be handled reliably.Support for nonstandard OAuth requirements—including mutual TLS, private-key client authentication, or other custom identity-provider behavior—should be validated during integration setup.AvailabilityGeneral Availability is planned for September 16, 2026.

    colemanCommunity Manager

    Permissive Log Redaction for Agent Studio2. On Roadmap

    How are we improving the product?Standard log redaction protects sensitive information, but it can also hide request and response details that developers need to troubleshoot HTTP actions. Permissive Log Redaction gives Agent Studio admins a more flexible option: preserve useful payload details in logs while continuing to redact header values.This helps development teams diagnose integration failures faster, reduce trial-and-error during testing, and better understand how an HTTP action behaved.How does it work?A super admin can enable Permissive Log Redaction as a security setting in Moveworks Setup. When enabled, Agent Studio logs use value redaction for HTTP headers rather than applying standard redaction to additional parts of the request and response.Developers can then inspect more of the logged HTTP action details, including request and response payload information, when debugging integrations.Licensing restrictionsPermissive Log Redaction is available as an Agent Studio security setting. Contact your Moveworks account team if you have questions about availability for your environment.Technical restrictions and security considerationsEnabling this setting increases the amount of request and response data that may appear in logs. Sensitive information included outside HTTP headers—such as an access token placed in a request body—may be logged.Before enabling Permissive Log Redaction, customers should review how their integrations handle credentials and sensitive data, ensure secrets are passed through headers where appropriate, and confirm that the additional logging aligns with their security and compliance requirements.DocumentationLearn more about log redaction in Agent Studio: Log redaction.

    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 Assistants2. 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.