I am trying to integrate Salesforce and Docusign. I'd like to send Create documents through a soap / rest call, and surpress the notification to the recipient. From Salesforce I'd like to send out the link to the envelope / documents through a branded email.
Is that possible? It seems like DS only supports a createAndSend call.
This documentation says I can create an envelope in draft form - https://docs.docusign.com/esign/restapi/Envelopes/Envelopes/create/ . It also says I get an envelope summary as a response.
https://docs.docusign.com/esign/restapi/Envelopes/Envelopes/create/#/definitions/envelopeSummary
As others have noted, Embedded Signing is the answer here. I've just done this with a client.
You would build the envelope with the SOAP API (good receipies from DocuSign on how to do this with APEX here: https://www.docusign.com/developer-center/recipes/docusign-for-salesforce).
When you define the Recipient, you would provide the ClientUserId in a CaptiveInfo object (use the ContactId for this). This tells DocuSign to skip sending the recipient an email, and you will handle this yourself.
Create and send the envelope (you can use templates as well).
You will need a portal or public Force.com site to move forward. The reason being that the URL for signing is a one-time-use link, and it expires 5 mins after it's generated. So you can't store it or send it in an email. By the time they click the link it will be dead.
So instead, you link to a Visualforce page you control. Add the ContactId to the URL as a parameter, so you know who is looking at the page.
When they load the page, you should have the Visualforce controller lookup the EnvelopeId (so if the page is about an Opportunity, you should store the EnvelopeId on the Opp or somewhere handy) and the recipient (use the ContactId to get the info about the recipient).
You then send this to DocuSign with the RequestRecipientToken method. It will return the token URL, and you can present it to the user.
Related
I have 3 applications:
An IdentityServer4 API which provides Google authentication and also provides an access token to authorize the resource API.
A simple Resource API which provides some data from DB.
A simple Client in React which have 4 buttons:
Login, for Google auth
Logout
Get data - a simple request with the access token to the Resource API and gets the data from Db
Get user data - returns user profile and token (for debug purpose)
I didn't put any sample code because my problem is not code related, it's knowledge that I'm missing and I ask for guidance.
The workflow is working just fine: the user press the Login button, it is redirected to IdentityServer4 API for Google Auth. From there it is redirected to a Callback Page from the Client and from there to the Index page. I receive the user data and the token, I can request data from the Resource API and it's working.
My problem is: How do I give a Role to the Google Users ?
I don't have users saved in DB. I want three types of Users: SuperAdmin, Admin, Viewer and each of these roles have limited Endpoints which can access.
For limiting their access I saw that I can use Claims-based authorization or Role-based authorization.
So, my question is how ca I give a Google User who wants to login in my app, a specific Claim/Role ? What is the workflow ? I must save it first in DB ? Or there exists a service from Google where I can add an email address and select a Role for that address ?
Thank you very much !
After you get the response from Google in your callback you can handle the user and do what ever you want to do with it. Below are the some typical tasks that you can do in callback that I took from documentation page of identityserver4 link:
Handling the callback and signing in the user
On the callback page your typical tasks are:
inspect the identity returned by the external provider.
make a decision how you want to deal with that user. This might be
different based on the fact if this is a new user or a returning
user.
new users might need additional steps and UI before they are allowed
in.
probably create a new internal user account that is linked to the
external provider.
store the external claims that you want to keep.
delete the temporary cookie
sign-in the user
What I would do is creating an new internal user account that is linked to the external provider and add a role to that user.
If you don't want to save users in db, you can add an extra claim to user in callback method and use that claim in token. and i think this link will help with that.
I'm using the gMail Node API to search for specific messages (not drafts) using the gmail.users.messages.list API, then I use the gmail.users.messages.get API to get the details for the message.
So I have the message id, thread id etc.... in the payloads returned. I present the user with the subject line from each message and I would like to also give the user a URL that will open the message in the gMail website.
If I use the gMail website to open one of the messages that are in my test bed the URL for gMail is:
https://mail.google.com/mail/u/3/#inbox/FMfcgzGljlhhRnrLbTDqXnNxSbhRcVCN
I could easily put that URL together myself but here are my questions:
Will the '/u/3/#inbox' portion of the URL always be the same for the authenticated user?
How do I get the ID at the end of the URL(beginning with FMfcgz...)? I searched the payloads from the API's and I cannot find that ID in any of the data returned.
I am sending some perameters to the third party application using rest api In one of the perameter I am sending A URL, This URL will use by third party application to send a json response after 5 or 10 min. My question is how may i create that URL for third party app that they will use to send the response.
If the 3rd party can send HTTP headers too you could send to them the current user's session id. If that user is API enabled (checkbox in profile/permission set) - you could write an Apex REST service that accepts POSTs. They'd call it with Authorization: Bearer <session id here> and it could work very nice. This trailhead might be a good start for you. (or can you contact their developers and maybe agree to make a dedicated user in SF for them so they'd log in under their own credentials and send it back?)
If they cannot send any special headers (it'd have to be unauthenticated connection to SF) - maybe you could make a Visualforce page, expose it as Site and then page's controller can do whatever you need. Maybe you already have something public facing (community?), maybe it'd be totally new... Check https://developer.salesforce.com/docs/atlas.en-us.206.0.salesforce_platform_portal_implementation_guide.meta/salesforce_platform_portal_implementation_guide/sites_overview.htm
If none of these work for you - does the url have to ping back to Salesforce. Maybe you have control over another server that can accept unauthenticated requests like that and have that one then call SF. Bit like a proxy. You could even set something up fairly easily on Heroku.
Last but not least. This would be extremely stupid but if all else fails - in a sandbox enable Web-to-Case or Web-to-Lead and experiment with these. At the end of the day they give you an url you can POST to and pass a form with data. I think it'd have to be Content-Type: application/x-www-form-urlencoded and if you mentioned JSON they're likely to send it as application/json so might not work. If it works - you could maybe save the payload in Description field of Cases (special record type maybe?) and do something with it. I'm seriously not a fan of this.
We are incorporating Powerforms into a Salesforce Community. When a user completes a Powerform, we need to execute a trigger to write back to Salesforce.
My questions are related to attaching the completed Docusign envelope to the related Salesforce record:
1) When we redirect from Powerforms, will we get the Docusign envelope ID?
2) If so, can we insert a Docusign envelope record in Salesforce with that ID with the standard AppExchange package to tie the envelope to the record in Salesforce from which the Powerform was initiated?
Any thoughts would be much appreciated.
Thanks,
Mike
If you're logged into DocuSign: Go To Admin>> Signing Settings>> In-Session Landing Pages
In-Session Landing Pages is used by Powerform to redirect the signer to the URL where you want Signer to redirects to. When Signer gets redirected then DocuSign populates URL like below:
{RedirectUrl}/?env={envelopeId}&pf={powerformId}&r={recipientId}
Alternatively and also recommended is to use DocuSign Connect, where you subscribe for the event like Envelope Completed or Recipient Signed etc, once event occurs then DocuSign will push an XML message to your configured listener with the envelope related details. This is a better approach because with redirect there is a risk of the customer closing the browser or browser getting crashed before browser hits your app URL.
I am a newbie to DocuSign integration with SalesFocre. I have DocuSign and Salesforce connected using connect settings, and am sending a DocuSign document from a custom object in salesForce. However, the DocuSign Status and the DocuSign Recipient Status are not populating on the Custom object. DocuSign Customer Support confirmed that my connect settings on DocuSign and salesForce are correct. In the DocuSign logs I can see the "dsfs__DocuSign_Status__c succeeded". But I do not see the same in the related list of the custom object. I can see the DocuSign status object in SalesForce shows all the envelopes but no related list records on custom object. The support person thinks that since the DocuSign integration is done using REST api, she will not be able to investigate the issue any further.
My REST api call is as per the sample code in DocuSign rest api implementation. However I do not know how do we notify the DocuSign of the relationship between the custom object and the envelope? I have not come across any documentation on this. Support person thinks that that might cause this issue. I am on a time crunch and will appreciate any help I can get.
If DocuSign Status and DocuSign Recipient Status aren't populating on the Custom Object in SFDC, I'd suspect that you've missed something in terms of configuration. I'd suggest that you verify that all settings have been configured properly (in both DocuSign and SFDC), as described in this article: https://support.docusign.com/guides/dfs-admin-guide-add-ds-status-to-custom-object.
UPDATE:
In response to your comment below that contains a SOAP code snippet, it looks like that snippet is simply adding a custom field to the Envelope. Do I understand correctly that you're creating the envelope using the REST API? If so, then the equivalent REST API request to add the custom field when you create the Envelope (in the same manner as your SOAP snippet appears to be doing) would be:
POST /v2/accounts/{accountId}/envelopes
{
"emailSubject": "EMAIL_SUBJECT",
"emailBlurb": "EMAIL_BLURB",
...
"customFields": {
"textCustomFields": [
{
"name": "DSFSSourceObjectId",
"value": "ID_OF_THE_CUSTOM_OBJECT_IN_SALESFORCE",
"show": "false"
}
]
}
}
Note: I've included the emailSubject and emailBlurb properties in this request example simply to show that the customFields property is a top-level property in the "Create Envelope" request body. Depending upon your implementation specifics, you may or may not be including emailSubject and emailBlurb in your "Create Envelope" request, and your request will most certainly contain additional properties which I haven't included in the example above. The important take-away here, as it relates to your question, is that in order to add a custom field when creating an Envelope using the REST API, you must include the customFields property as a top-level property in the request body, as shown in the example above.