I'm using Docusign's API to send reminders and expirations for a given envelope. I have seen that it is possible for Admins to disallow users by overwriting reminders and expirations defined in the DocuSign account.
The information about if is possible to "overwrite" or not is only available in an account endpoint and as a result the endpoint is available only for admin users.
As a non admin user how can I know if I can overwrite established reminders and expirations? So that I'm able to display to the user what he is capable to perform.
Docusign's own UI is able to block the user under the circumstances described above but I don't seem to understand which information they use for it.
Which is the correct API endpoint for the above use case?
Regardless of that account-level setting, the API can always override the account's default reminders and expirations.
In other cases where the API can't override locked settings, making a GET call against the resource using the v2.1 API with include_metadata=true will add parameters that will tell you if a parameter is locked or not. More information on that is "Improved usability" section here: https://developers.docusign.com/docs/esign-rest-api/esign101/new-v21/
As an example, you could create a draft envelope and do a GET call against it with include_metadata=true and include=recipients to tell if a particular recipient is locked for editing or not.
That said, the account settings endpoint Inbar listed is accessible for both users and admins. I called that endpoint as a non-admin member of my account and received this in the response:
"userOverrideEnabled": "false",
"reminders": {
"reminderEnabled": "true",
"reminderDelay": "44",
"reminderFrequency": "33"
},
"expirations": {
"expireEnabled": "true",
"expireAfter": "22",
"expireWarn": "11"
}
},
Related
We are developing a PowerAutomate Flow to automate the process of inviting external users to a SharePoint Site.
Below are the steps being followed so far
Created an MS Form for an external user to register
Passing the response**(Email)** from the form to the flow
Adding the user to a SharePoint Group using email parameter and sending an email invite to the External User(Requirement)
I have been able to get to point no 2 , However I have been experiencing challenges achieving point no 3
Came across different articles online for adding a guest users , However most of them talk about adding the guest to Azure AD as shown below
https://medium.com/southworks/adding-a-guest-to-an-office-365-sharepoint-site-with-javascript-fa7604ad8678
https://laurakokkarinen.com/how-to-build-a-guest-user-self-service-registration-for-office-365-with-azure/
https://www.timlinenterprises.com/how-to-invite-external-users-using-microsoft-flow-and-microsoft-graph-api/
Also checked a few articles for running PowerShell commands from Flow , However this approach doesn't look straightforward either
The below article works only for internal users
https://www.c-sharpcorner.com/article/add-the-users-to-the-sharepoint-groups-using-microsoft-flow/
The end goal here is to invite external user to a SharePoint Site once the user registers himself through a registration form (MS Form)
Would appreciate if anyone could help me out in achieving this.
Thanks in advance
Before inviting the user to SharePoint you must add him to Azure AD. So you will need to configure an HTTP action to invite the user first.
If you are using SharePoint Modern Sites (those who have Microsoft 365 groups associated), you need to create a HTTP action to add the guest to the group:
HTTP Action Configuration Here
NOTE: HTTP will not accept "#" sign directly, so you need to put it into a "Compose" or "Variable" and add it as per my screenshot.
In the URI you have the Group ID from Azure AD.
In the Body it's the guest user ID
You will need to register and Azure AD App to use for the HTTP action and give it the following permissions:
Graph -> Application -> GroupMember.ReadWrite.All, Group.ReadWrite.All and Directory.ReadWrite.All
https://learn.microsoft.com/en-us/graph/api/group-post-members?view=graph-rest-1.0&tabs=http#permissions
Use the App ID and Secret to connect the HTTP action.
This is my solution to add Guest Users to Private Channels in MS Teams with PowerAutomate.
Step0 - Register the domain of the Guest Users in your AD account as a valida Guest Domain
Step1 - User a registration form (MS Forms)
Step2 - Create a Trigger Process in MS PowerAutomate to receive the Form Data. I like to create small/short flows to only capture and validate form data, and then call a separate Flow / RestService. This makes your solution a little bit more decoupled and reusable. (Imagine replacing the Form with a web app form or mobile app form in the future).
Create a second HTTP request trigger flow receiving the Form data (optional way to setup multi-flow solution)
Step3 - Create a Private Channel in teams via GrapAPI
GraphAPI - POST https://graph.microsoft.com/v1.0/teams/<teams_id>/channels
POST BODY:
{
"membershipType": "private",
"displayName": "<e.g. channel name from form data>",
"description": "<e.g. description from form data>",
"members": [
{
"#odata.type": "#microsoft.graph.aadUserConversationMember",
"user#odata.bind": "https://graph.microsoft.com/v1.0/users('owner.user#mydomain.com')",
"roles": [
"owner"
]
}
],
"#odata.type": "#Microsoft.Graph.channel"
}
Step4 - Call GraphAPI to retrieve the Guest User Details
GraphAPI: GET https://graph.microsoft.com/v1.0/users?$filter=mail eq 'guest.user#email.com'
I have added this in a loop - since I had many members who had to be added - and I also included a condition check to check if the domain is indeed valid
Now you can assign the output (or portions of the output) to some variables
Step5 - Retrieve the ID value from the step above (Step4). This is the value that must be used to add the new guest member.
Retrieve the ID from the Step4 output
Also set a variable to the account type - which should (MUST BE) be "guest"
Now - Add guest users to the private teams channel
Step6 - Call GraphAPI to add guest members
GraphAPI: POST https://graph.microsoft.com/v1.0/teams/<team_id>/channels/<channel_id>/members
Post Body:
The role must be "guest" for guest account
But valid options for other types of access can be
owner
member
guest
Microsoft documentation (HERE) states roles must be owner or empty
This did not work so well for me.
Use guest
{
"#odata.type": "#microsoft.graph.aadUserConversationMember",
"roles": [
"#{variables('membership_type')}"
],
"user#odata.bind": "https://graph.microsoft.com/v1.0/users('#{variables('principal_user')}')"
}
Bonus Step
Now you can catch all responses from the previous steps and respond back with an HTTP Request/Response connector.
A 200 response on successful executions
A non-200 response on failed executions (or how ever you desire)
To configure exception handling or failure handling responses do this below
I'm trying to achieve ID Check on embedded signing through an envelope sent via Docusign Java SDK. I am able to make it work through remote signing however, I get the following error on embedded signing.
{
"errorCode": "INVALID_REQUEST_PARAMETER",
"message": "The request contained at least one invalid parameter. The value of AuthenticationMethod is invalid."
}
I'm fully aware of another post on the same topic posted in 2013 (DocuSign ID Check with Embedded signing). The difference here is that I'm not using any document templates but sending the documents in the envelope itself. Based on the comments a bug was logged with bug id 30830 but I can't say whether this was resolved.
Also, I have already added the settings that I know that are required for ID Check.
signer.setRequireIdLookup("true");
recipientViewRequest.setAuthenticationMethod("ID Check $");
Can anyone advise on what I'm missing ?
It's a little hard to tell from your question but from what I gather you might be setting the properties on the wrong request. As you know when creating a remote signing request you can do it through just one API request - Envelopes: create.
For embedded signing you still first create an envelope (with an embedded recipient) but then you need to generate the signing URL by calling EnvelopeViews: createRecipient.
When setting the ID Check authentication for your recipient you still need to assign this in the first request (ie the create envelope call) so that recipient is configured like so:
"recipients": {
"signers": [
{
"idCheckConfigurationName": "ID Check $",
"requireIdLookup": "true",
...
}
]
}
THEN, in the request body of the second call you need to set the authenticationMethod with the same value and provide the other required params to identify the signer.
Please confirm you are following this flow and if so and still stumped then post the actual JSON that you are sending for your requests and we should be able to determine from there.
I have an application that creates an envelope via the API and stores the envelopeId, name (subject), and status.
Our application shows this envelope information and offers a "view in DocuSign" button, so that the user (who might be the sender or possibly a recipient, but maybe neither) can view the envelope in DocuSign to see its full history, or to edit it if permitted.
This button invoked createSender method in EnvelopeViews to open a browser tab on the DocuSign page. This works fine when the user is the creator of the envelope or was given shared access to the envelope by the creator. (Via DocuSign Admin.)
However, if the user isn't the creator (owner), createSender shows an empty editor page with the message, "you have no envelopes".
Edit: I have switched from createSender to CreateConsole, which is better: it takes the user to their home page when the envelope isn't accessible to them.
I understand the need for limiting access, but is there a way of detecting an envelope's ownership or the current user's rights to view it prior to generating and utilizing the createSend or createConsole methods? Then we could clearly report, "You don't have permission to view this envelope" or such.
There clearly is a concept of ownership and sharing. It is quite surprising that this information isn't available when reading the envelope's metadata.
If there is really no efficient way to know if the envelope can be viewed, I guess I'll invoke the createConsole method and let the user discover if they can view the envelope or not.
There is no way to know an envelope's ownership. But I think below solution should give you an overview if the user can access the envelope or not (either shared with him or he is the owner of the envelope).
a. Call GET /v2/accounts/{accountId}/folders this will list all the folders which user has accessto, it also includes the list of the folders for other users who has shared envelopes with this user.
b. Response to above call will list all the folderIds which this user has accessto, like below sample, It will show all the folders which this user owns or shared with this user.
{
"folders": [
{
"ownerUserName": "AnotherUser Test",
"ownerEmail": "anotheruseremail#gmail.com",
"ownerUserId": "a832164e-0da7-449c-9405-be21632564a4",
"type": "inbox",
"name": "Inbox",
"uri": "/folders/2980d14d-461b-4229-9ae7-b9d0c64371ea",
"folderId": "2980d14d-461b-4229-9ae7-b9d0c64371ea"
},
{
"ownerUserName": "AnotherUser Test",
"ownerEmail": "anotheruseremail#gmail.com",
"ownerUserId": "a832164e-0da7-449c-9405-be21632564a4",
"type": "sentitems",
"name": "Sent Items",
"uri": "/folders/507050da-3817-47be-a20c-142374a50493",
"folderId": "507050da-3817-47be-a20c-142374a50493"
},
{
"ownerUserName": "OriginalUser Test",
"ownerEmail": "amitkumar.bist+test#gmail.com",
"ownerUserId": "87b00103-461d-487b-8928-1991dfdb8d19",
"type": "inbox",
"name": "Inbox",
"uri": "/folders/b98cd590-c7b4-469a-bf7c-dd3be19d3763",
"folderId": "b98cd590-c7b4-469a-bf7c-dd3be19d3763"
}
]
}
c. Then call GET /v2/accounts/{accountId}/folders/{folderId} to know all the envelopes available in the folder. Check if your envelopeId is present in this list or not, if not then that user does not have access to that envelope.
I would try calling Envelopes::get with the potential viewer's credentials. If that call succeeds then I believe they will have access to view all of the envelope's info via the DocuSign web tool.
After running the console app, our users get an email with the signing link to Docusign making them remote signers.
What I want to be able to do is get those links from their emails.
I did some research and this is what each url is made of
https://demo.docusign.net/Member/EmailStart.aspx?
a=65d11cf7-d3b7-49a1-8000-6192b6227d71& <<< Unique Activity ID? Always different in all URLs
acct=a0e816ac-3919-475e-a826-34c2c33f90e7& <<< Some kind of role ID (stays same between envelopes and users of the same role, I have it
for my roles..just don't know how to get it programmatically
er=62378ec0-39ce-495e-84e4-e0e598fab3cc& <<<< envelopesApi.ListRecipients(.....) .Signers[n].RecipientIdGuid, able to get it
espei=30cec285-39cd-45a3-bb8e-7bd0560dcd80 <<<< ENVELOPE ID, able to get it
The first parameter is the main focus of my question - it is a total mistery what is it and how to get it
The second parameter looks like a role_id, but I don't know how to get it other than hard-coding values for each of my roles
The other two parameters aren't a concern.
Does anybody know how to get ahold of the first two parameters using the C# Docusign API?
Or even better, is there a way to get the recipients signing url links using the same API?
To obtain the signing URL you will have to set the recipient as an embedded recipient.
After the envelope is created, use the createRecipient:EnvelopeViews api to retrieve the Signing URL.
You have to set the recipient clientUserId parameter to mark a recipient as an embedded recipient.
Request
{
"userName": "name",
"email": "examble#email.com",
"clientUserId": "clientUserId",
"authenticationMethod": "email",
"returnUrl": "your app url"
}
I'm working on a PHP application that has multiple products which require signing from a customer before going for the product.
I'm using powerforms link to embed them on my application (using iFrame).
They work fine. But the problem is I need to store the document signed status in my database.
The we can set a return URL in the Docusign Preferences Page. But that will be static and I won't have a clue of what product the user has selected.
References:
Powerform Docs
You can use DocuSign Connect to receive real-time notifications of envelope events (for example, Envelope Completed). At a high-level, it works like this:
You login to DocuSign web console (as Admin) and create a Custom Connect Configuration. As part of creating this configuration, you'll specify the endpoint (http address) that you want Connect to send notifications to, and which events you want to be notified of.
You build a "listener" -- i.e., the web page that will receive the HTTP POST messages from DocuSign Connect, and process those messages.
When an Envelope or Recipient event occurs (for which you've enabled notifications in your DocuSign Connect Configuration), Connect will almost immediately send an HTTP POST to your listener. This message contains XML with info about the Envelope, Recipients, Documents, Fields, etc. You'll develop your listener such that it parses the XML message to determine Envelope status, data field values, etc. and then can respond appropriately within the context of your application (i.e., in your scenario, your listener would use the XML message from Connect to determine envelope status and which product(s) the user selected).
See this guide (http://www.docusign.com/sites/default/files/DocuSign_Connect_Service_Guide.pdf) and this page in the DocuSign Dev Center (http://www.docusign.com/developer-center/explore/connect) for more detailed information on configuring/using DocuSign Connect.
UPDATE - Using Custom Fields to populate unique Identifier for Envelope
Depending on the nature of your use case, you might need to use an "envelope custom field" to populate a unique identifier for each Envelope in the "create/send envelope" request, so that your listener application has a way of identifying the envelope when it receives a Connect message. (An 'envelope custom field' is simply a custom piece of metadata on an envelope.) Simply set the customFields property in your Create Envelope request, and populate a single textCustomFields item with the unique identifier. For example:
{
"emailSubject": "Please sign this",
"emailBlurb": "Please sign...thanks!",
"customFields": {
"textCustomFields": [
{
"value": "1234567",
"required": "false",
"show": "true",
"name": "ProductId"
}
]
},
"status": "sent"
...
}
See the REST API Guide (http://www.docusign.com/sites/default/files/REST_API_Guide_v2.pdf) for more detailed info about using Custom Envelope Fields.