Group Signer in BoldSign: Secure Team-Based Signing with Directories

TL;DR: Group Signers in BoldSign are controlled using directories attached to Contact Groups. A directory is a simple label that tells BoldSign which groups are allowed to sign for a request. This approach is built for systems where the signing authority belongs to a team instead of an individual, preventing the wrong people from signing and removing the need for custom signer checks in application code. 

BoldSign controls who can sign as a group by enforcing directory‑based rules at runtime.
Group Signers are validated using directories attached to Contact Groups, ensuring only authorized teams and only their members can sign. This prevents incorrect signers, removes fragile UI‑level checks, and keeps group‑based signing secure even as teams and tenants change.

Why group signing breaks

Group signing often starts with a basic idea: send a document to a team and let anyone from that team sign. Over time, this stops working. Teams change, members rotate, and embedded signing flows allow users to choose signers dynamically. When access rules exist only in the UI or application logic, documents can reach the wrong group and be signed by the wrong person.

BoldSign avoids this by enforcing signing rules at runtime. Each Contact Group has a directory, which is a label that tells BoldSign whether the group is allowed to participate in signing. BoldSign checks this label every time a document is sent or signed, so only approved groups and their members are allowed to proceed.

How group signers are checked

When a document is sent using a Group Signer, BoldSign does not assign the document to a specific person. It first validates the Contact Group included in the request.

BoldSign checks whether the Contact Group has at least one directory and whether any of those directories are allowed for the request. If the group fails this check, the API request is rejected and the document is not sent. If the group passes, the document continues without assigning an individual signer yet.

This validation happens every time a document is sent or a template is created using a Group Signer.

Why contact groups without directories are rejected

A Contact Group without a directory cannot be used as a Group Signer.

If a GroupId without a directory is included in an API request, BoldSign rejects the request immediately. No signer is created and no document is sent. This ensures every Group Signer is intentionally scoped and prevents accidental use of unrestricted or legacy contact groups.

What happens at signing time

An individual signer is decided only when the document reaches the signing stage.

At that point, BoldSign looks at the Contact Group linked to the Group Signer and allows only members of that group to sign. Even if someone outside the group gains access to the signing link, they cannot complete the signing action.

This ensures directory checks control not just which groups are valid, but also who can actually sign the document.

How do developers control which groups are allowed?

Developers control which Contact Groups BoldSign can use when sending a document or creating a template by specifying allowed directories.

With this configuration:

• BoldSign accepts only Contact Groups tagged with the SalesTeam directory.
• Any request that references a group outside this directory is rejected.
• Only members of the allowed groups can become the signer at signing time.

Note: In multi‑tenant systems, use UUID v4 values (e.g., 550e8400-e29b-41d4-a716-446655440000) instead of human‑readable names to prevent directory name collisions across tenants. 

What happens in embedded signing workflows?

In embedded signing workflows, users often search for and select signer groups.

When group signer settings are enabled, embedded signing workflows allow users to search for and select eligible signer groups. This prevents accidental signer selection and removes the need for client‑side filtering logic.

How are directories assigned to contact groups?

Directories are assigned when Contact Groups are created or updated using the API. They cannot be managed through the UI, which keeps signer rules centralized and consistent across environments.

Contact group API endpoints

Directories are assigned and managed exclusively through the Contact Groups API:

Who is directory‑based group signing designed for?

This behavior is designed for systems where the signing authority belongs to teams, departments, or roles rather than individuals. It works especially well for embedded signing platforms, internal approval workflows, and multi‑tenant applications where users should not see or use every available signer group.

If the rule is that someone from a specific team must sign, BoldSign enforces that rule automatically.

Real‑world use cases for group signers with directories

Below are practical, real‑world use cases that highlight how directories enable and enhance group signing workflows. 

How BoldSign keeps teams and tenants isolated

BoldSign checks directories for every request.

Only Contact Groups that belong to allowed directories are accepted. Groups outside those directories are fully blocked, and their members can never become signers. This isolation applies even when multiple teams or tenants share the same infrastructure.

Final takeaways: Secure group signers in BoldSign API workflows

BoldSign treats Group Signers as a runtime decision, not a UI shortcut. When a document is sent or signed, the system validates the Contact Group, blocks unauthorized access, and assigns signing rights only to approved group members. This removes the need for user‑level permission logic and keeps group signing workflows reliable as teams and systems change.

Ready to secure group signing with directories? Sign up for a free sandbox account  and explore what BoldSign can do for you.  

Need assistance? Contact our support team via the support portal  or schedule a personalized demo today.  

FAQs