Build better products with our product team.
Are there plans on the roadmap to enable the bot to read images?For example, reading error messages uploaded by users and the bot being able to recommend corrective steps from their knowledge.
In the ServiceNow platform , Majorly forms uses the client scripts.The UI policies and Client scripts enhance the forms and create a great user experience.The challenge for us is we have 149 forms and nothing is supported by BOT.How we can overcome that challenge ?Do Moveworks has any plan to improvise the product to support the UI policies and scripts.
Hi Team,Country tagging on the title works well however there are instances specially in HR wherein there are multiple countries are to be tagged and putting all of the country names in the title will sometimes exceed character limitations. We would like to request for the Country tab to also be ingested and identified as a criteria for knowledge when it is being served as a result. This ensures better accuracy as well as ensure that articles created will only be available to the users in the specified countries. HR articles have confidential processes that should not be visible from one country to another.RegardsSujit
We are working on a use case for SAP Approval. There is a Approval API in SAP ECC System, and the approver name should be on the actual user who approves it.To achieve the SSO we have configured Microsoft Azure AD as Identity Provider and SAP as Service Provider.Below is the end-to-end process of a user authentication:The user is redirected to the Azure AD tenant’s authorization endpoint (https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/authorize) in order to authenticate and to acquire an access token for the API. The user has to enter their credentials and give consent to the requested permissions to access the API. Once the user is successfully authenticated, the redirect URI receives an access token for the API in response from the authorization endpoint. To allow the Azure AD authorization endpoint to issue an access token the OAuth2 implicit grant flow must be used. The user is now authenticated and the front-end has acquired an access token that can be used to call the API on behalf of the logged-on user. This token cannot be used to authorize the call to the backend service in SAP NetWeaver. Services in SAP only accept access tokens issued by their trusted OAuth Authorization Server. The SAP OAuth Authorization Server accepts the SAML Bearer Grant type, which allows the API in Microsoft Azure to request an OAuth access token from SAP with a SAML 2.0 assertion. Azure AD provides a SAML assertion by receiving an OAuth access token (issued by the Azure AD tenant to the authenticated user before) in exchange. The API App is using the SAML 2.0 assertion by sending a POST request to the SAP OAuth Authorization Server to receive Bearer token from SAP. Once the SAML assertion is exchanged with an access token, the final POST request can be sent to SAP e.g., service from SAP using the access token to authorize the call on behalf of the logged-in user in Azure.How can we implement this flow through Moveworks creator studio, with the current capabilities how can we allow user to open a browser link from the bot and give the consent?
On a Service Now (SNOW) ticket, the “Affected User” and “Watchlist” users will get notified in AVA whenever the Proactive Notification skill is triggered. However, we would also like to notify the “Caller” when updates are made to the ticket.
Currently, when a user who is not the caller of an incident tries to check the status of the incident in the bot, they receive the response below (as show in the screenshot). However, the message lacks clarity and does not explain why they are unable to view the ticket's status.Can Moveworks, update this message to something more meaningful that informs the user they are not authorized or do not have the necessary access to view the details of the ticket they are searching for?
Hi Team,We have noticed that the long descriptions users provide before starting a live chat through the bot are being trimmed.Upon analysis, we found that ServiceNow Workspace has a 160-character limit applied to the short description field. However, on the Moveworks side, the input box allows for more than this limit, causing issues when users enter details exceeding ServiceNow’s restriction. This forces users to repeat their issue to the agent, leading to a negative experience with the bot. Could we implement a character limit on the input box to align with ServiceNow's restrictions? Live chat option - long descriptionRegards
Hi,Would be extremely helpful if channel resolver could include posted screenshots in the ticket. Todays behavior provides a URL to the screenshot, but would be a big efficiency gain if the screenshot actually showed in the ticket.
Hello when requesting a new feature (in our case “Brief me” feature”) we stumbled on the next option to “Allow Moveworks to send promotional message”. It would be great that there was also checkboxes to choose and limit the preferred way, for example Email, Bot Message, etc… so customers can chose for example Email distribution but avoid spamming Bot messages.
I am trying to add emojis to a button, but it is not working as expected. This functionality was working in the Classic version, but it is not working in the Copilot version.Can you consider this feature and provide the solution
When there are multiple option buttons in a Paths use case the bot gives a "View all option" button on click of which a pop up opens up which shows all the multiple choice button options that we have configured in the path use case using ask a question action. For the Share Una Feedback path use case we have noticed that inside the pop up the bot shows the variable name instead of the question detail as a label for the multiple choice options.Expected: Question Detail should be shown in the pop up as labelActual: Variable name which we configure for the question is shown to the user as label
Hi Moveworks Team!Requesting an enhancement that allows us to hide ServiceNow Incident close notes from being shown during an Incident Resolved notification. Today, Incident close notes are not at all viewable to the customer. These close notes typically contain the fix the agent completed to resolve the issue, rather than a customer visible update. Impact: We would be exposing a field via Moveworks that colleagues dont have access to or see today.
On behalf of Swire, could we please add Lenovo as a documentation source.
For customers who’ve integrated Workday approvals, users are presented with a very long Workday ID when they click on ‘View next approval’ or ‘View all approvals’. While this means something systematically to the Moveworks agent, it gives a poor user experience and could seem there is some sort of error. Request that this ID either be removed/hidden or masked to be user friendly.
Hello Moveworks Team,I would like to request the creation of an application space where we can directly add utterances to forms (record producers and catalog items), rather than raising a ticket each time to add them.Ideally, the template could be designed similar to how utterances are added for query and path requirements in Creator Studio. This implementation will not only assist us but will also be beneficial for all clients using Moveworks.Thank you for your consideration.
We recently launched Moveworks to the business which included the implementation of Channel Resolver. We could definitely see the value in this feature however have some feedback on how the experience could be improved for both the user and agent:How it currently works: Employee asks question in channel eg. peopleinfo-triage Bot identifies whether it has access to knowledge that could assist the employee If it determines with a high confidence that it can assist, it will DM the employee with a response At this point an emoji will appear below the original employee query in the channel Employee receives bot DM and is asked to rate the response as ‘helpful’ or ‘unhelpful’ If ‘helpful’ a tick emoji is added to the original message in the channel If ‘unhelpful’ a greenflag emoji is added to the original message in channel and GF agent reaches out to assist GF agent will then add a tick emoji once issue is resolved Challenges and feedback with current solutionBot DM - By design, the bot interacts with the user in DM. This presents a couple of challenges for agents: If employee rates response as unhelpful, agent has no sight on why that is the case and so has no context when the employee returns for more help There is a desire from teams outside of IT, HR etc to adopt Channel Resolver. However, in these instances, there is a lot more nuance to the issues they resolve. So, not having any visibility over the interaction between the bot and the employee is a blocker to adopting Channel Resolver. When testing the inclusion of ticketing in Channel Resolver we found that the flow was not as intuitive as it could be: User comes to channel Bot then redirects user to a DM to assist User rates response as unhelpful which then redirects them back to the channel again At which point they need to manually add a ticket emoji in order to raise a ticket Ideally the flow would be: User comes to channel and raises issue In the thread the bot attempts to assist If user rates response as ‘unhelpful’ they are immediately offered the option to raise a ticket Additional Feedback It would be helpful if an agent could be defined per channel. As it stands today, setting an employee as an agent is a universal setting. So, for example when a Finance agent, reaches out for help in the HR support channel, the bot will not respond. We’d like the ability to introduce other skills to Channel Resolver (eg. Creator Studio use cases)
It would be great if moveworks could proactively reach out to users who have never initiated an interaction with the bot or users who haven’t in over X amount of time, perhaps either 6 months or a year. The nudge would just be a reminder to the user that the bot is still around to help them with whatever capabilities are available. Another way would also be to find users whom have had X amount of Incidents or Requests created but had never interacted with the bot to create those Incidents or Requests. Again this would be the same nudge to remind them that they could use the bot to submit those easily for them and possibly provide an answer or get them access.Something like this might help drive up adoption for those that may not have used it before or possibly used it and didn’t have a good experience but after so long new functionality may be available or more knowledge to help them.
Already have an account? Login
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.