> For the complete documentation index, see [llms.txt](https://help.sdocs.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.sdocs.com/s-sign/template-configuration-fields-profiles-settings/define-signer-profile-and-routing.md). # Define Signer Profile & Routing The following table outlines the Signer Profiles Settings that are available through the template editor and describes them in detail. | **Name of Setting** | **Detailed Description of Functionality** | | ------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Signer Profile ID | Denotes the specific signer profile number (e.g., Signer 1, Signer 2). By default, two profiles are created. New profiles are assigned incremental IDs. | | Profile Name | A custom internal label for the profile (e.g., "Customer" or "Manager"). This is independent of the signer's actual name and defaults to "Signer \[ID]". | | Email Address | Specifies where the signature request is sent. Supports hardcoded emails, comma-delimited lists, or dynamic merge fields (e.g., `{{!Opportunity.Email}}`). If left blank, the sender is prompted for an email during generation. Email address must be associated with a Contact Record or a No Contact Record. | | Signer Name | An optional field to enter the legal name of the signer. This field also supports merge fields and special shipping/billing contact picklist fields. | | Signing Order | Determines the sequence of the workflow. For example, setting one signer to "1" and another to "2" ensures the second person only receives the request after the first has finished. | | Verification Type | Controls identity authentication. Options include enabling 2-Factor PIN code verification (sent via email) or disabling it to allow the document to be opened directly from the email link. | | Prevent From Viewing Audit | When enabled, this specific signer will not see the secure audit trail attached to the finalized document. (Note: Requires "Prevent Certain Signer Profiles From Receiving The Audit Record" to be checked in Template Settings). | | Prevent From Receiving Confirmation Emails of This Type | A picklist that allows you to stop a signer from receiving automated confirmation emails after they sign, or after all subsequent signers have finished. | | Prevent From Receiving Document In Confirmation Email | A checkbox that, when selected, prevents this specific signer from receiving the finalized, signed PDF copy once the process is complete. | | Email Address is provided by previous signer if: | Uses conditional logic (e.g., `{{!Opp.Amount}} > 100`). If true, the *previous* signer in the order will be prompted to manually enter this signer's email address during their own signing session. | | Signer Profile is omitted if: | Uses conditional logic (e.g., `{{!Opp.Stage}} == 'Closed Lost'`). If the condition evaluates to true, this signer profile is completely skipped and removed from the signature request. | | Delete Profile | A button used to permanently remove the selected signer profile from the template configuration. | | Create Another Signer Profile | A button that adds a new signer profile to the list, allowing for multi-party signing workflows. | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://help.sdocs.com/s-sign/template-configuration-fields-profiles-settings/define-signer-profile-and-routing.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.