I'm having trouble making this work. I have an embedded signing view for my users as well as email notifications that are sent to the user as the flow progresses, such as perhaps reminders or CC's when signing is complete.
From what I understand the UI and the email are controlled separately
The UI is supposed to pick up on the browser settings and display accordingly
The email I can set in the emailNotification setting in the Recipient through the API for each recipient
I haven't gotten around to number 2 yet, but please confirm. As for the first, I have changed my browser (Google Chrome) to be in Spanish through their Settings/language and Input settings. Relaunched Chrom and it is in Spanish. For instance the Settings page is all in Spanish. But when I click on the signing link on my page and it takes me to the embedded signing view, it still is in English.
How can I ensure the UI will be in Spanish for my Spanish customers? I don't want them to have to set it themselves via the hard-to-find language control at the bottom of the page.
Thanks
Joe
Setting the emailNotification/supportedLanguage on the Recipient changes both the language presented in the embedded signing view as well as any email notifications that recipient gets. This despite contrary information I have seen in these forums and is the only way I got it to work. The embedded view DID NOT pick up the language set in the browser as is alleged throughout this forum as well as in DocuSign support documents
Related
I have created a contact form under Forms with first name, last name, and email that is designed to sign up people for a newsletter. I then created a page so when people click on the link placed on the home page it takes them to a page with the contact form.
Right now when I test the subscribe form out, the data does to to the "back office" where it can be retrieved. However, the information I entered is still in the text fields and, unless you notice the small flash of the web page, one might think nothing happened.
I'd like to know how (or be directed to somewhere in the Kentico 8.2 Documentation) I can make it so that the fields clear and a message appears saying "You have been subscribed to the newsletter." That message can either appear on a separate page on the web site, or send a message to the user email, or both. In the Email Marketing part under the templates there are Subscribe and Unsubscribe templates, but I don't know how to use those.
The other issue is creating an Unsubscribe link. Ideally that will open up to a new page saying "You have been unsubscribed." Kentico 8.2 has an unsubscribe page you can create where the user enters in an email address and then hits the Unsubscribe Request button, but I'd rather not do that. As it stands, I did create a page with that form and tested it, but it doesn't seem to work.
When you edit your form, under general tab, there are settings for what will happen after the form is submitted:
Display Text
Redirect to URL
Clear Form
Continue Editing.
Currently you're using the standard Forms application for something which can be managed through the Newsletter/Email Campaign module. Read the documentation more on how to configure this vs. using the Forms application.
Essentially the steps you will do are:
Create your newsletter following the directions in the linked documentation.
Place a newsletter subscription webpart on your page template and configure it to the newsletter you want them to subscribe to.
Use the out of the box unsubscribe feature to allow users to unsubscribe to your newsletter. No need to add any page to the content tree but you can if you want OR just use the OOTB functionality.
If you follow the documentation you should be able to get it setup properly vs. using an online form.
I'm using DocuSign's REST API to create envelopes in embedded signing mode.
I authenticate the signers on my website, then ask DocuSign for recipient view. Users can sign documents, that's ok.
My problem is: the embedded signing view is in english, whereas my users may speak other languages.
As an example, how to redirect signers to embedded signing view in french?
I saw "emailNotification" option when adding signers to an envelope (https://www.docusign.com/p/RESTAPIGuide/Content/REST%20API%20References/Recipients/Signers%20Recipient.htm). But it looks like it is about language of email notifications sent by DocuSign to signers. I guess it does not apply to my use case, because I use embedded signing mode, where my website sends email notifications, DocuSign doesn't.
Note: I do not want to translate the documents in envelope. I want signers to display DocuSign's user interface using their native language.
DocuSign supports most languages for signers via a UI user control at the bottom of the screen that allows the user to choose the language, including you when testing. The assumption is that setting the emial notification language means that user is using that language and thus the "browser default" will already be set to that language.
You DO NOT set the language that the browser will view the envelope in, only email noticifications, the user/signer sets that in the browser (known in the drop down mentioned as browser default) or by manually selecting what language they want to view the signing experience in.
Here is a link to the supported language documentation https://www.docusign.com/support/classic/documentation/cdse-user-guide/console-overview/supported-languages
Response #2 above no longer work on my case instead on the Summer '15 release, the language parameter should be appended to the response URL.
This is done by appending a locale parameter (&locale={languageCode}) to the URL provided in the response to a POST recipient view request before loading it in your iframe or web control/view.
eg:
https://demo.docusign.net/signing/startinsession.aspx?t=d1cf42f2-30b6-499b-ab54-058fbf438103&locale=fr
Setting the "emailNotification" language does also control the language the signer gets in the UI when they are signing. It's not documented that way but I have it working. Yes it's odd because for an embedded scenario you'd assume you have no need to set that value.
You might need to make sure you have "Set Recipient Sign Language" checked under Preferences -> Features. I recall that I needed to have DocuSign enable that so I could see it as an admin, then check it. That, combined with setting the language inside "emailNotification" did work.
** Update **
For new Docusign UI, the setting is under: Admin >> Sending Settings >> Fields and Properties >> Enable custom email and language for each recipient
I would like send an envelope with below two options.
Here we go,
User should sign in SignTab if it is first page of document.
User can sign anywhere if it is other that first page.
Is it possible to have this option using docusign API.
If Yes, Please let me know what are the parameters should I send?
Unfortunately you can only have it one way or the other currently- either you make the signing experience a Free Form signing experience (meaning the recipients can place tabs anywhere they want on any page of the envelope), OR you set 1 or more tabs in the envelope document(s) and the recipient will only be able to take action on those tabs and they will not be able to place tabs wherever they want.
The DocuSign Developer Center has a page devoted to Stick-eTabs under the Features section, they also talk about Free Form signing further down:
https://www.docusign.com/developer-center/explore/features/stick-etabs
We have implemented the embedded signing process and at last step we get the embedded url. So, what we want is when I click on the embedded url I want to see the document in another language for eg. Norwegian.
Is it possible that using DocuSign API we can view documents in another language like Norwegian.
Thanks and Regards
Sandeep
DocuSign will always present the documents in the same exact state as the sender supplies them in -- having DocuSign translate the documents to another language, or make any other changes to the documents is not possible. The ability to configure "language" in DocuSign applies only to the DocuSign web console UI and other instructions that DocuSign displays to the Signer during the signing process -- not to the documents themselves.
While sending email from lotus notes to Gmail using Lotus Script, buttons are not visible in Gmail.
As Anders says, Any standard or custom Action Buttons (at the top) will not be available in Gmail. You would need to code your own Gmail interface to reproduce.
If you are talking about buttons in the actual rich text of the mail, these will definitely not get translated when the mail leaves and you should get a message saying...
"The following items cannot be sent or saved in MIME (internet mail) format."
That would be a clear sign that you are going to need to take another look at your assumptions.
If you are planning a migration, you do need to check your assumptions (and your vendor's promises) carefully, there is a lot of infrastructure and functionality that is taken for granted in the Notes/Domino stack and just not available, or significantly different, in others.
Stored forms are a feature that is unqiue to Notes. They contain Notes design elements, formulas and scripts that execute Notes functions that are provided by the Notes API DLLs that are only available in the Notes client. GMail doesn't know anything about them. Outlook doesn't know anything about them.
But if you want to send them to someone who has a GMail address but who also has the Notes client, then there is a way to do it manually using the "Send this email to other Notes mail user(s) through the Internet" feature, which appears in the Advance tab of the Delivery Options dialog that you can bring up when sending a message. There is no simple API for automating the mechanism that is used, but it can be done. It requires creating a new empty database file with a special name (encap.ond), saving your document into that database, and then attaching the the file to a new message, which will be the one that you actually send. I don't recall if any special headers are required for this, so if you want to pursue it you will have to do some investigation by using the manual process and checking out the full headers of the message on the receiving side.