Basic Concepts

Organization and other Core Data

When creating an account or trial account on eSignAnyWhere, you are already creating an organization entity (i.e. a tenant). The first user account is created within that organization. This is a design principle of eSignAnyWhere Workflow solution, as it is designed as a multi-tenant platform.

Within that eSignAnyWhere organisation, following administrative objects exist:

• Organisation: The organization itself typically reflects the legal entity for which the sender is collecting signatures. The first user's name is used as organization name by default, but the organization name can be configured later on. The organization is also the unit for which the license applies, at least in the SaaS deployment scenarios.
• User: As mentioned above, during account registration, the user is created within a generated organization structure. Remember that a user is always part of an organization. But within one organization, additional users (depending on your license and select plan) can be added by the organization administrators.
• Roles & Permissions: We already mentioned above the role "organization administrator". In general, the roles assigned to a user define the permission set of the user, and it is possible to assign more than one role to a user. The role “Administrator” belongs to an administrator of the organization and is automatically granted to the first user of an organization. The “Power User” is a user, who can send envelopes to request signatures. The “Registered Signer” can use eSignAnyWhere as a signing platform to sign his/her documents and can use it as an document inbox. Beside registered signers, unregistered signers (which do not have an account on eSignAnyWhere) can be invited to sign a document; but they cannot log in and don't get e.g. an envelope overview. Beside this three primary roles, the predefined roles "Api User", "Automatic Sealing Sender" and "Developer" can be assigned to a user to use specific product features.  In the roles and permissions guide we go more into details and also explain how to define and use custom roles.
• Teams: Teams, if included in the purchased package, can be used to group users within an organization. Teams are used to share templates and envelopes in between team members and the teamlead, or within team members. 

Envelopes

Basic Idea: Send a document via eSignAnyWhere to a signer (recipient) and collect the signed document later.

With eSignAnyWhere you are creating envelopes, which define the signing workflow. An envelope can contain one or many documents (all related to the same business case). Those documents are sent to the recipients to collect signatures, to get a receiving confirmation or just to deliver a copy. The workflow can contain sequential or parallel activities. This allows to design your own signing workflows from very basic to complex. In addition, the product supports sending bulk envelopes - a concept where copies of the same envelope are sent to a list of recipients, and all need to sign their independent copy. Also the use of automatic remote signing certificates (stored in an HSM in the premises of the trust service provider) or hiding certain documents from some recipients within a workflow is supported.

The simplest possible signing workflow would be sending one document to one recipient, who has to sign the document.

You can use eSignAnyWhere for simple signing tasks and for complex tasks e.g. signing a project order, which has to be signed by some managers. A lot of features allow you to design many different signing ceremonies and use cases. In addition you can use our SIGNificant product suite to extend your use case possibilities (e.g. use native iOS/Android apps and SDKs, Signature Pads or even biometric signature verification options).

Workflow Capabilities:

• Sequential recipients: one after another
• Parallel recipients: all recipients without specific order must sign
• Bulk recipients*: each recipient will get a unique copy of the envelope (e.g. if you want to send out a new company policy, first signed by the responsible manager and then each employee gets a separate copy of the envelope for signing)
• Document Hidding*: hide certain documents from specific recipients
• Meta Information: allow to store meta information per envelope (e.g. for hybrid integration; sending envelopes via UI and automated post processing [auto-archive] via finish callback)

Recipient Types:

• Signer “needs-to-sign”: the recipient must sign the document (or can reject it)
• CC “receives a copy”: the recipient receives a copy of the document
• Needs to acknowledge: the recipient must open the document
• Automatic Remote Signers: via Namirial TSP an automatic signature/seal is applied to the document*
• P7M (PKCS#7) Signer: a specific feature to sign with a PKCS#7 signature*

* optional feature