I try to set up the email channel for a bot on the Azure portal using a company email address. The address uses password authentication. When I try to save I receive Unable to save. Unable to validate the given credentials. ID: b8f65400c0bbb04890efdfa2950940d1. Is this supposed to work?
If I use a company test tenant with an email address ending in onmicrosoft.com registration succeeds.
The only difference I see when doing one of the connection tests on https://testconnectivity.microsoft.com/ (Mailbox provisioning test) is that I get a company login page with the company email address and the standard Microsoft prompt with the onmicrosoft account.
There may be another way, but for my organization, we found the same thing and the solution was for us to create an onmicrosoft.com email address to use for the email channel for the bot. It shouldn't actually matter if you only have access to do this in the test tenant; all you're doing is setting up a channel to communicate with the bot, and you can give you bot access to connect to your production tenant if there are functions there you need.
Related
I've signed up for a developer account with Docusign. We have about 15 users that access a Windows Forms page from another program where they fill out the proper information and click a button that calls a NET Core Web API which creates an envelope and sends to the signer. Those 15 users don't have accounts in Docusign and don't need them to. I want to use one admin or service account that will send and receive the emails, but I can't figure out how to do this.
I used my name for the developer account and now all my (test) Docusign emails show they are from me and once the signer signs, my email receives the signed documents. I've tried creating another "Admin" account, but I don't see any way to associate that user as an "API User". When I try using that user's GUID as the ImpersonatedUserID, my RequestJWTUserToken request comes back with "consent_required". But, when I go to the link I just get an error with "The client id provided is not registered with Docusign".
Everything in the Web API is working perfectly except for the emails showing they are from me and then the signed docs coming back to my email. This should be an easy thing to change the user, but apparently it's not, or I just can't figure it out.
You were on your way to fix this, but didn't follow through.
Create new user (you did it)
Find the new userId (you did)
Update JRequestJWTUserToken (you did)
Consent error - expected, the new user did not consent.
Obtain consent. You need to have a URL built correctly like this to do this:
https://account-d.docusign.com/oauth/auth?response_type=code&scope=signature%20impersonation&client_id=7c2b8d7e-xxxx-xxxx-xxxx-cda8a50dd73f&redirect_uri=http://example.com/callback/
Once you do 5, you need to log in with the same new user account you created (you may be automatically logged in with your original developer account, so log out) and provide consent.
Then step 4 will work just fine.
https://developers.docusign.com/platform/auth/consent/obtaining-individual-consent/
I am looking for solution/code/custom policy to customize/update email which is being sent over user email address when ever he is being instate MFA for his account login
SAMPLE FORMAT BELOW WHICH NEED TO BE UPDATED OVER EMAIL which is being sent to customer along with OTP
the subject and email format of the OTP for the customer onboarding process should be:
Subject of the email: XYZ Company registration - [OTP number] for authenticating user
Body of the email:
Thank you for initiating the process of registering to our XYZ company online. Please use the [OTP number] to validate your email address.
In case you have not raised this request, please contact our Customer Service Centre on 18000 077 or email Customer.Helpdesk#xyz.au and we will be more than happy to assist you.
Regards,
Use custom email in Azure Active Directory B2C (Azure AD B2C) to send customized email to users that sign up to use your applications. By using the third-party email provider SendGrid, you can use your own email template and From: address and subject, as well as support localization and custom one-time password (OTP) settings.
Custom email verification requires the use of a third-party email provider like SendGrid, Mailjet, or SparkPost, a custom REST API, or any HTTP-based email provider (including your own)
Note: Azure Active Directory B2C offers two methods to define how users interact with your applications: through predefined user flows or through fully configurable custom policies.
For more details refer this document:
I am using the Docusign Apex Toolkit in Salesforce to send emails as outlined here:
https://developers.docusign.com/salesforce/code-examples/salesforce-sending-signing-template
The email is sent when a case field is updated to a specific value via a trigger.
This works perfectly if I am a signed in user. However, if the user doing this is a guest then the following error is thrown:
You must have DocuSign sender permissions to perform this operation
Class.dfsle.Permissions.verifyIsDocuSignSender: line 300, column 1↵Class.dfsle.Permissions.verifyIsDocuSignSender: line 295
As this is the guest user I am unable to assign the permission sets to them as there is no user.
I have given permissions to all dosusign objects and fields to the guest user profile.
How can I allow emails to be sent automatically via apex in a trigger for guest users?
DocuSign envelope can be created only by users who have DS Account and have atleast a Sender permission. It is like GMAIL, you will be able to send an email from GMAIL domain if you are a GMAIL user.
So in case of the Guest user, they will come to your App but your App should make DS API call to DocuSign with any System user credentials (like apiuser#system.com) who is a user in your DS Account. Auth Type Doc explains this type of flow.
We are using Azure B2C for our Identity provider, but it is clear that users are finding the process a bit clunky. Mostly this appears to be because of the synchronous nature of the signup process.
We do want to verify the email address and MFA phone number, but ideally not at the point at which they are entered. Is there a way that we can leverage a graph API call to deal with this, or use a custom policy to achieve the same?
We would also like a clear separation of the signup/signin process. Such that a user can be directed to these pages directly and they can also be branded.
You might be able to implement this with two custom policies:
A sign-up policy that prompts the new customer for the email address and the phone number and creates a new user with these marked as unverified. This custom policy can be invoked at the Account Creation step.
A verification policy that verifies the unverified email address, via the built-in email message, and then the unverified phone number, via the built-in phone call or text message. This custom policy can be invoked at the Application Complete step.
Note that it isn't the sign-up policy that sends the verification code but the verification policy that sends it. I don't know if this is acceptable for the desired experience but the custom policy that sends the verification code must be the same one that validates it.
(There is an alternate flow where after the sign-up policy has completed, your end application sends a custom email message, containing a verification link, which when opened by the end user is validated by your end application and then the verification policy -- minus the email verification step since the email address has already been verified -- is started).
If this proposed solution is interesting to you, then I can attempt to provide the full details of the custom policies based on one of the custom policy starter packs.
Updated on 15 February 2019
I've published the following custom policy samples to this GitHub repository. The second and third policies implement the above flow.
sign_up_sign_in
Sign-up for a local account using an e-mail address and a phone number. The end user is prompted for verification of the e-mail address and the phone number.
Sign-in for a local account using an e-mail address or a phone number. If the e-mail address hasn't been verified, then the end user is prompted for verification of the e-mail address. If the phone number hasn't been verified, then the end user is prompted for verification of the phone number.
sign_up_without_verification
Sign-up for a local account using an e-mail address and a phone number. The end user is not prompted for verification of the e-mail address or the phone number.
sign_in_with_verification
Sign-in for a local account using an e-mail address or a phone number. If the e-mail address hasn't been verified, then the end user is prompted for verification of the e-mail address. If the phone number hasn't been verified, then the end user is prompted for verification of the phone number.
I want to send emails from a G Suite Google Group address e.g. group#mydomain.com. The account I will be using to send emails is in another G Suite domain, e.g. user#anotherdomain.com. I can verify the access with a confirmation code, but I am required to provide an SMTP account as well. I provide an SMTP username/password on the same G Suite Domain as the group, e.g. smtpuser#mydomain.com:
Now whenever I send an email from group#mydomain.com, the emails always show up as originating from the email I provided for the SMTP username, smtpuser#mydomain.com rather than the group address of group#mydomain.com.
I've struggled with this configuration forever and finally got an answer! You have to make sure the user information provided for the SMTP configuration is also configured to send email on behalf of the group.
So in the example I posted, you need to configure smtpuser#mydomain.com to send email from group#mydomain.com as well as configuring user#anotherdomain.com to send email from group#mydomain.com.
I sure hope this helps save someone time!!