Skip to main content

    Filter by idea status

    Filter by product

    1294 Ideas

    navya.kandiNew Participant

    Enable redirect URL in bot and allow the user to give consent3. Existing Functionality/Native Skill

    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? 

    jchretienNew Participant

    Allow the Bot to add user to security group3. Existing Functionality/Native Skill

    The bot is actually able to create DL and add user to DL. The bot can also add user to group for software provisionning.If the bot is able to do both of those thing, it should be able also to add user to security group. Adding user to security group can reduce the number of ticket coming to IT service desk for users that require access to a group. That group can provide access to folder on an onPrem file server, but also can provide access to a 365 Sharepoint folder. This can be also a Microsoft Teams group.We manage a lot of things with groups and having the bot the functionnality to add or remove users to or from a group will help a lot service desk.Example: User 1 is asking to get access to Purchasing department group. The user should ask the bot, “Please add me to the Purchasing-Denvers group”. The bot follow workflow and request approval to Manager or specific user.Example: User 1 is asking to get access to Purchasing department. group. The user should ask the bot. “Please add me to the Purchasing group”. The bot could answer “We found multiple group containing Purchasing, which one should meet your requirement?” Actually the bot is only creating a request to the IT service desk and once we get the approval from the manager, we only need to add the user to that security group. If the bot can do it, send the approval the manager and once the manager approve, the bot can automatically add the user to that security group.The bot is already listing DL groups, users and other, that should not be a problem to list security groups and add user to a group when user is requesting it and got approved.

    Nick PolianlisNew Participant

    Channel Resolver Feedback4. Future 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)