we are working on a custom software integration with DocuSign.
DocuSign has many types of accounts and subscriptions providing certain limits of features and credits for these features. E.g. you can create 5 documents - so you have 5 credits to create documents.
We have custom software and one corporate DocuSign account within it, enterprise level.
And there are numerous (account1, account2, account3, etc.) accounts of DocuSign users. These users work with our custom software and as a result our corporate account.
We have a question:
our custom software connects to account1, account2, account3, etc. using our Key. And our custom software creates envelopes(documents) in account1, e.g.
From what account credits are written off?
From our corporate DocuSing account or from DocuSign user account?
Thank you.
The user account should have the appropriate subscription to send envelopes.
Related
We recently submitted our Add-in for approval to be available on AppSource/Office Store and failed approval. Some of the feedback and policies make sense and we have addressed those items. However, there are a few policies that I'm not sure how to address and looking for guidance.
Policy 7.1 & 7.16 are about the supportURL not being publicly available and requiring Sign-in. Our add-in is not a general user add-in but targeted to Enterprise Customers of our Platform. They are provided a login for our support site so is this not sufficient? Do we really need a public url for an add-in targeted to Enterprise Customers?
As I was writing this I found the following link and wanted to make sure this was still valid and the same guidance for my scenario: App Submission - Help/Support Link Requirement
Policy 11.3 are about the Start-up experience needs to engage the user and show value proposition. Our users are Enterprise Users and have signed up for platform in which we will already guide them to use the Excel Add-in. Since they already know the value proposition from our sales team is there a way that this can be handled in our scenario without needing an explicit startup video or wizard walk through of app features?
Yes, this must be a public URL. The support link in your Seller Dashboard listing appears on the AppSource website so must be publicly available. It can be a link to your main website / or a contact page on your main website.
Have you seen the documentation on submitting Enterprise add-ins? This outlines which policies are not applicable when submitting an add-in which targets larger organizations and enterprises. It also explains how to declare, via test notes, that you are submitting an Enterprise add-in.
We are developing a Word Web Add-In that will be used exclusively by our customers rather than the general public. Customers will need to log into the Add-In in order to use it with credentials we supply. My question is, is this Add-In ok to be distributed via the Office Store? Will it fall foul of the validation process if its functionality is not publicly available ? Obviously, we can supply credentials to the verification team at Microsoft in order to get the app published.
If this is a problem, how do ISVs distribute Web Add-Ins to customers external to their organisation (i.e. Without Sharepoint or Office Admin Centre)?
This model is supported via the Office Store - this blog post on add-ins which target organizations and enterprises rather than consumers may be of interest to you.
Please ensure that your add-in description clearly states the need for an additional account, as well as supplying test credentials for the validation team to use.
I am new to GCE and I see there is a quota for all the resources I create under a project / region, but I do not see the projects. How many projects can a user create?
As far as I know, an account may allow the developer to register up to 25 free applications and an unlimited number of paid applications, which is stated at doc of How many applications can I create with Google App Engine?.
I have developed an online ticketing application that uses a simple form integration - it's been running successfully for some years.
I have been asked to extend this so that it can be used for phone payments.
The reason for this is that the ticketing application has a great many options before the final price is arrived at so the people taking the call could use the same software (with minor modifications).
I can't see any options in the integrations for doing anything like this. It's all for customer payments.
Can anybody tell me if this is possible (and if so, how)?
Here's my understanding. It comes down to AccountType when you make your request to Sage Pay.
That accepts three different values:
E - use ecommerce account
M - use MOTO (mail order/telephone order) account
C - use continuous authority account.
Depending on your merchant bank and what you requested when you set up your merchant accounts, you'll have a merchant account for each. Sage Pay will send your request to the correct merchant account. This is key because if you use M, you'll not be expected to use 3D secure for the card - and the expectation is that it will be you processing the card, not the customer.
I'm trying to help a school move to 'Google Apps' but i have concern.
One of the features I need is to retrieve current user's email upon form submission..which is only available if i purchase 'Google Apps for Education'.
Another concern is that since they already have existing email accounts, wouldn't they be hesitant to use new email accounts created from 'Google Apps for Education'?
What are your experiences so far in helping clients or businesses with Google Apps?
If you are moving an organization over to Google Apps your will achieve the best results if they fully embrace the ecosystem, including migrating all their email accounts to Google Apps.
There should not be anything preventing users from keeping their existing email addresses, simply set up identical account names in Google Apps and adjust their DNS MX records to deliver mail to Google's servers once you are ready to go live.
You are correct that if you want to automatically obtain the account names of users submitting forms then you need to be on a paid Google Apps account. This also lets you use their own domain for their Google Accounts, hence the ability to keep the same email addresses. Attempting to move to the free consumer-level #gmail.com environment rather than a paid Google Apps environment is not advisable as you lose most of the functionality that makes Google Apps great for organisations.
In my experience, if the users are unhappy with their existing system and you can demonstrate the benefits of Google Apps to them (low costs, universal accessibility, and collaboration functionality) they will be enthusiastic about moving over. If they are not interested in the benefits Apps offers and do not embrace the change, then there will be conflict each step of the way as you attempt to have them embrace a new way of doing things.