Skip to main content

    Filter by idea status

    Filter by product

    1344 Ideas

    akaneishiiNew Participant

    [Moveworks]Request for a feature to dynamically retrieve and display manual/knowledge information in a plugin1. New

    We would like to request the ability for custom Agent Studio plugins to dynamically search and retrieve relevant content that has already been indexed by Moveworks.To clarify our use case, we are not requesting real-time Web search functionality such as Live Search, nor are we looking to use the built-in Enterprise Search plugin directly.Our specific use case is as follows: We have internal knowledge sources already configured and indexed in Moveworks, including: Manuals stored in Box Knowledge articles stored in ServiceNow A user submits a query to a custom Agent Studio plugin. Based on the user's query, we would like the custom plugin to dynamically search the content already indexed by Moveworks and retrieve the most relevant internal knowledge. We would then like to provide the retrieved content as context to an LLM Action, such as generate_text_action or generate_structured_value_action, so that the LLM can generate a response based on the relevant internal knowledge. Ideally, this should be possible without having to specify individual files, articles, or knowledge resources in advance within the custom plugin. In short, we would like custom Agent Studio plugins to have a mechanism to dynamically access and retrieve relevant content from the knowledge sources already indexed by Moveworks, and use that retrieved content as context for subsequent LLM Actions.This would allow custom plugins to make use of newly added or updated knowledge without requiring individual knowledge resources to be manually configured in each plugin.We understand from Moveworks Support that this capability is not currently available for custom Agent Studio plugins, so we would like to request it as a Product Idea.Thank you for considering this request.

    jared.zabelNew Participant

    [EmployeeWorks] Allow Filtering Before Searching in Enterprise Search1. New

    SummaryEnable users to apply filters in EmployeeWorks Enterprise Search before initiating a search, rather than requiring an initial search before filters become available.Current ExperienceToday users must first enter and execute a search before they can access filters to narrow the results. For users who already know the scope or type of content they want, this creates an unnecessary step and consumes an additional assist before they can perform the search they actually intended.Requested ExperienceAllow users to configure available filters before executing a search.The desired flow would be: Open Enterprise Search Select the desired filters Enter the search query Search within the selected scope Receive relevant, filtered results immediately Users should still have the option to search without applying filters first.ExampleIf a user knows they only want results from a specific source or content type, they should be able to select that filter first and then search, rather than:Search → Review results → Apply filter → Search/refine againThe preferred experience would be:Select filters → Search → Receive targeted resultsBusiness ValueThis enhancement would: Reduce unnecessary assists and interactions Help users reach relevant results faster Make Enterprise Search more intuitive and efficient Reduce searches that users already know are too broad Provide users greater control over their search scope upfront Improve the overall EmployeeWorks search experience Acceptance Criteria Users can access available Enterprise Search filters before submitting a search. Users can select one or more filters before entering or executing a query. The initial search respects all filters selected by the user. Users can modify or clear filters after results are returned. Users can continue to search without selecting any filters. Applying filters before search does not require an additional assist solely to expose filtering options.

    iamzainulNew Participant

    Fine-Grained Access Control and Field-Level Data Minimisation for Moveworks Data API1. New

    The Moveworks Data API currently allows API credentials to be scoped to specific data entities, but consumers retrieving an entity can receive all fields and records available within that entity. There is currently no native mechanism to restrict API consumers to an approved subset of fields or records.For enterprise customers, particularly those using Data API data for analytics and reporting, this can result in sensitive or personally identifiable information being exposed to consumers even when it is not required for their use case.We would like Moveworks to provide fine-grained access controls for Data API credentials, allowing administrators to control not only which entities an API credential can access, but also which fields and records can be returned.Proposed capabilitiesWhen creating or managing a Data API credential, administrators should be able to configure: Entity-level access Continue supporting selection of permitted Data API entities. Field/column-level access Define an allowlist of fields that the credential is permitted to retrieve. Row-level filtering Optionally restrict records according to approved attributes, such as business domain, geography, department, or other supported dimensions. Sensitive-field protection Allow selected fields to be excluded, masked, or pseudonymised before data is returned through the API. Credential-specific access policies Different API credentials should be able to have different access profiles. For example: Analytics credential: pseudonymised interaction data Operational credential: detailed operational attributes Privileged credential: full dataset for specifically authorised support/security purposes Auditability Administrators should be able to review which API credentials have access to which entities and fields, and ideally audit changes to those permissions. ExampleToday an organisation may need interaction metrics for a Power BI dashboard but does not require employee identity or free-text conversation content.Rather than:Data API → full interaction dataset → downstream filtering → Power BIthe desired pattern would be:Data API → policy enforced by Moveworks → approved fields/records only → Power BIThis ensures that sensitive information is never exposed to the API consumer in the first place.Business valueThis capability would:Support the principle of least privilege. Improve privacy by design and data minimisation. Reduce unnecessary exposure of PII and potentially sensitive conversational data. Reduce the need for customers to build middleware solely to filter or mask Data API output. Make the Data API more suitable for enterprise analytics and multi-consumer scenarios. Allow security/privacy controls to be applied consistently at the source rather than relying on every downstream consumer to implement them correctly.Why this mattersThis is more than a Power BI/reporting requirement. It becomes increasingly important as Data API information is consumed by analytics platforms, AI agents, automated processes, and multiple enterprise applications.

    gsachdevNew Participant

    Improving the Conversational Experience – What Controls Are Available?1. New

    Hi Community,I’m interested in learning more about the controls available to customers for fine-tuning the conversational experience in Moveworks, across Slack, Microsoft Teams, and the web experience.As we expand the number of use cases and agents available through Moveworks, we’re looking at the experience beyond just answer accuracy …. specifically, how the bot communicates and interacts with employees.For example, there may be situations where we want to influence things such as:Response length and level of detail Tone and conversational style Use or expansion of acronyms Formatting and structure of responses Follow-up questions and clarification behavior How frequently the bot asks for feedback How references, actions, or help options are presented Consistency of the experience across Slack, Teams, and webWe’ve seen that some conversational behaviors can be adjusted by the Moveworks team. For example, we recently had a change implemented to minimize the use of acronyms and expand/define them when they are necessary.That example made me curious about the broader model.What controls are available to customers today to fine-tune the conversational experience themselves, and what controls remain managed by Moveworks?I’d also be interested in understanding the process for making these adjustments. Is there a configuration layer, prompting/instruction framework, admin capability, or other mechanism customers can use to influence bot behavior? Or do certain conversational changes require Moveworks Product/Engineering involvement?Ultimately, I’m trying to better understand the boundaries between customer-configurable conversational behavior vs. Moveworks-managed behavior, and what options exist for continuously improving the employee experience as our use cases grow.Would appreciate hearing how others are approaching this as well.