I have 2 queries based on the following :
I recently followed this DocuSign article to pass a supplied document to Docusign via the API:
https://www.docusign.com.au/blog/get-the-flow-sending-docusign-envelopes-microsoft-power-automate?_ga=2.99447774.1174083755.1646148960-1179341585.1645460870
Query 1 - This all works apart from the AutoPlace text just isn't getting picked up. I added the variables as described in the article and referenced them in the document footer. The document is passed through the API call and the invitation to sign goes out ok. Is there anything I'm missing here? I can open the document for signing but docusign doesn't go to the places where the AutoPlace tags are, just leaves it open for the user to decide what to do. I've previously tried using AutoPlace using templates, but this is a document that will be sent through the API as it is provided by our users (with the correct AutoPlace intact). The article hints this should just work.
Update : this is now working but need advice on text color
signing screenshot
Update : Showing white signature on black background
white signature
Query 2 - Once the user has signed the document using the above, I want to trigger a power automate flow off. There is a trigger for this but when I try to form the connection to DocuSign, there is only a login for the main account, not the developer account. So the account where I've made the account from isn't the one where I can fire off the triggers from. This makes it impossible to then fire a flow when it has been sent to the API and subsequently signed. Is there a way to use the trigger using the same account as the API account? If not it seems a bit crazy that I can start the process using the API but then can't fire flows from the result of the signings.
We have a company account ( I'm working on behalf of Transport for Wales) but was told there is no API support at all, which also sounds a bit bizarre. Hoping someone can help me!
Query 1 - there's an AutoPlace settings that determine the scope - document/envelope for AutoPlace. You may want to see if the issue happens also when you use the web app and not from API - if the same challenge - then you need to contact support to change this scope. If not, it may mean you're not setting your templateRole correctly. It must match the same one that was defined on the template (case sensitive).
Query 2 - no, the OTB connector is production only. For the developer account you will need to use a custom connector for any REST API, not the one provided for you.
Related
I understand how to brand my login form but how to customize the workflow that Azure provides?
Currently the Sign-up form looks like this:
Which is really unlogical. The text boxes under 'Verificatiecode verzenden' (Send verification code) are only useful after the code has received and filled in.
How to customize this part to create a better working workflow:
Add email address -> Send code -> Fill in code and verify --> Fill in additional user details.
Edit:
As recommended by Brad I dived into Identity Experience Framework. An 'intimidating' framework is a big understatement ;(
I watched these videos: https://www.youtube.com/playlist?list=PL4svy-vB4AaxRunWQkxOe8h3zP9jAzS5Z and followed the steps mentioned here:
https://github.com/azure-ad-b2c/azureadb2ccommunity.io/wiki/LocalAndSocialAccount-Sign-In-and-Sign-Up-policy
https://github.com/azure-ad-b2c/samples/tree/master/policies/split-email-verification-and-signup
I'm just at the point that I only want to mimic what I currently have using the 'normal' user flows:
Log-in using Email
Log-in using Facebook
Log-in using Google
The login screen looks the same, I have the email and password buttons and the Facebook and Google buttons, but when I log in with Google I get an error about grant-type not set.
And this is all without trying the split.xml.
I'm so lost in understanding AAD B2C. It should make live easier for developers but I find it very complicated, hard to modify and hard to get the profile data I need and to keep the data in sync.
In order to achieve this with User Flows, you must use the Custom User Interface features, and Javascript to control how and when those fields are displayed.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/javascript-and-page-layout?pivots=b2c-user-flow#enable-javascript
Optionally, you can conduct a similar flow using the Identity Experience Framework (Custom Policies) with either Javascript or where you use two different Self Asserted profiles to move from screen to screen.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-trust-frameworks
Taking the leap from User Flows to the Identity Experience Framework can be intimidating, but would give you the most control in your user experience.
Running into a bit of an odd issue. I assume it may be a setting somewhere?
Using the API integration for embedded forms. We have two brands, so I've made two users with the same roles. Their job is to be the sender for any embedded form for their respective brand. Their roles are both set as sender from the user settings tab.
support#brand.com
support#other-brand.com
Each user is in 2 groups, developers and their respective brand. Simply being part of developers will allow them to be assigned as the sender of any API templates. It's worth noting, these two users are identical to one another in setup, only difference being support email.
Using user 1, there are no issues, and everything works as intended. Using user 2 however, I get the error "consent required" when trying to get a JWT token?
I've gone through all and any settings I could find, but nothing seems to do what I need. Both users belong to the organization, so I'm simple confused.
Any help and direction is much appreciated.
The answer was I needed to claim the #brand URL the 2nd user was under, which had not been claimed via the application admin interface.
Consent is per user, you would need the second user to log in and navigate to the URL For consent.
If you are using the developer/sandbox/demo environment (not production) the URL you would want to set looks like this:
https://account-d.docusign.com/oauth/auth?response_type=code&scope=signature%20impersonation&client_id=<your IK>&redirect_uri=<some URL you defined for the IK>
Remember to define the redirect_uri in the Apps and Keys page in the settings page where you created the Integraiton Key and you should be good.
My use case is thus:
I will have access to a single DocuSign account which would belong to Acme Inc. (I am currently using a sandbox account).
Acme Inc. has many branches, each with it's own employees with different documents that they must sign depending on which branch they work in.
From my internal application, the Admins of the branches will upload documents and set the emails addresses that the documents must be sent to.
The employees will complete the signing ceremony after following the link in the mail that they will receive.
MAIN ISSUE - Once the signing ceremony is complete, I require the employee to be redirected to a certain page of the internal application where they must complete some additional steps.
What I have so far:
I ran the example provided here. The issue with this is the permission request. I do not want an access prompt, rather, I want this done in the Admin Panel itself so that requests to the DocuSign API from my Server Application contain a valid token or receive a new one in case the existing one has expired. I saw from here that the JWT Grant system fit my use case, and I ran that using consent from a single user, however, I am stuck trying to figure out how to redirect the signer (employee) to the page I want with some parameters in the redirection URI. This can be as simple as the one provided (state=123) in the (eg-01) Embedded Signing example provided with the Auth Grant sample.
I apologize for not having any code snippet to show as I have not integrated anything into my internal application as of yet, I am merely running the code from the GitHub examples. Please let me know if I need to provide any additional information in order to facilitate your understanding of my requirements.
Any help provided would be much appreciated!
I think your main issue is the authentication type you are using.
You used the example showing Auth Code Grant, which does require users to log in.
You could instead use JWT (JSON Web Token) which does not require that (only once, and that can be done by you).
The code for making APIs and redirecting after signing ceremony etc. is the same. All you have to do is change the code that was used to obtain the access token (and also you need some configuration changes).
You can find nodeJS example of JWT here - https://github.com/docusign/eg-01-node-jwt
If you want to read more about JWT - https://developers.docusign.com/esign-rest-api/guides/authentication/oauth2-jsonwebtoken
I have some doubts regarding the custom connector we are trying to build for docusign : -
Regarding the license plan that need to be bought by the customers who will be granting access for our connector to collect data from their docusign organization account. I am looking at the link https://www.docusign.com/products-and-pricing. API access support is mentioned in only the advanced solution. So I was wondering whether only we need to have "Advanced solutions plan with APIs support" plan or all our customers need to API access support in order to fetch their data.
As per the documentation, to make the REST API calls we need two fields 'base_uri' and 'account_id' (https://developers.docusign.com/esign-rest-api/guides/authentication/user-info-endpoints). Now, the response of userInfo API call gives an array of accounts and its respective fields. My doubt is, if multiple authenticated users (more than one accounts) are returned in this array but all are part of same organization, will they all have different account_ids. Main concern here is, will there be several Base Paths (https://developers.docusign.com/esign-rest-api/guides/authentication/user-info-endpoints#form-your-base-path) to make API calls?
2a. Further question is, what is the significance of 'is_default' field?
Is this related to main account (if is_default is true) using which we will create our Base Path?
Since this is a tech/engineering forum I'm going to answer only question #2 as question #1 is more of a business/sales question.
The reason you may get multiple accounts is that an authenticated user in DocuSign can be a member of multiple accounts. That said, it's the same user. Meaning, say foobar#blah.com has an account 123 with company X and account 456 with his school, then it's possible that when foobar#blah.com authenticates (With the same password!) to DocuSign we have a list of accounts associated with that user. We give you all of them when you make the API call. The default one is the main one that you would see when you log into our web app. You can decide yourself as the user which one is the default. Users who log into our web-app then see an option at the top-right to change accounts.
and yes, every API call is associated with a specific account. So when you construct the urls for your API - you do need to know which account for this user you are making the API call for. Your application can decide how to handle this.
Hope this helps.
It appears that it is possible to generate an envelope using a template that does not belong to the account that was authenticated in the REST call. The two accounts were completely unrelated. Access to the generated envelope is limited to the account that generated the envelope; however the access to the template seems to be allowed to any account.
Scenario where this behavior was noticed:
- Account 1 - Created Template #1
- Account 2 - Generate an envelope using Template ID generated by Account 1
I could not find documentation or configuration related to behavior.
I need to confirm if the behavior is intended/supported before we plan to utilize the functionality.
Probably your best solution if you want to use Templates from one account in another is to simply move them. You might only be able to do this in the classic UI so you might have to switch back through your preferences, but you can:
Download the actual XML for each template you want to "share" across accounts.
Open the second account and select to upload template(s) and chose the XML files you downloaded.
As mentioned you might have to switch back to the classic UI to download/upload, but you definitely will not be able to use Templates from one account when you are an un-authenticated user in another account.