Dropbox Sign Integration

Scimify enables SCIM provisioning for Dropbox Sign team members, allowing you to invite users, manage team roles, and place users on sub-teams through your identity provider.

Overview

This integration (de)provisions users on your Dropbox Sign team. Scimify accepts standard SCIM requests from your IdP and translates them into Dropbox Sign team API calls.

Key behaviors:

User-only — no group provisioning
Invite-based provisioning — new users are invited to the team (they must accept before they are active members)
Role management — optional dropboxSign_role SCIM attribute maps to Dropbox Sign team roles on invite
Sub-team placement — optional dropboxSign_team_id SCIM attribute places the user on a specific team or nested sub-team
Deprovisioning — Scimify removes the user from the Dropbox Sign team (including sub-teams) or cancels a pending invite
Document transfer (optional) — Enterprise plans can configure a default recipient for removed users’ documents

Prerequisites

A Dropbox Sign account with team features and an API key from API settings
Permission to invite and remove team members
Your IdP or identity governance platform (IGA) configured for SCIM provisioning (see SCIM Configuration)

For API details, see Dropbox Sign authentication and Team API.

Configuration Steps

1. Create a Dropbox Sign API Key

Sign in to Dropbox Sign
Open API settings on your account
Create or copy/reveal an API key

Note: A dedicated service account user is recommended for the API key so the integration doesn’t break on employee lifecycle changes

2. Configure the Integration in Scimify

Navigate to the Integrations page in your Scimify admin console
Create a new Dropbox Sign integration instance
Set an instance display name (for example, Production Dropbox Sign Team)
Enter your API Key
Optionally set Document transfer email (see Enterprise document transfer)
Save the configuration and use Test connection to verify API access
Use List Teams to copy team names and IDs if you will map users to sub-teams with dropboxSign_team_id
Enable the integration and copy the Scimify SCIM endpoint and API key for your IdP

Your Dropbox Sign root team is determined by the API key. Use dropboxSign_team_id when you need to place users on a specific sub-team.

3. Configure Team Role Management (Optional)

To assign Dropbox Sign team roles via SCIM, add the dropboxSign_role custom attribute to your IdP user profile and map it into the SCIM user payload.

If dropboxSign_role is omitted, Scimify assigns the default role Member.

4. Configure Sub-team Placement (Optional)

To place users on a Dropbox Sign sub-team, add the dropboxSign_team_id custom attribute and map it to the target team’s team_id.

To look up team IDs without calling the Dropbox Sign API yourself:

Open the Dropbox Sign instance on the Integrations page in Scimify
Click List Teams (next to Refresh Users)
Copy the team_id for the root team or the nested sub-team you want, then paste it into the IdP dropboxSign_team_id mapping

List Teams is a manual mapping helper only — it does not provision users or change SCIM state.

If dropboxSign_team_id is omitted or empty, Scimify invites the user to the root team associated with your API key.

A user can belong to only one Dropbox Sign team at a time. Changing dropboxSign_team_id moves the user to that team.

5. Configure SCIM in your IdP or IGA

Follow the SCIM Configuration guide to connect Okta or Lumos to your Scimify Dropbox Sign instance, then assign users as needed.

Enterprise document transfer on deprovision

Dropbox Sign Enterprise plans support transferring a removed member’s documents, templates, and API apps to another team account when a user is removed from the team.

In Scimify, set Document transfer email to the email address of a team member (typically a dedicated service account) who should receive those assets when users are deprovisioned via SCIM. Scimify passes this value as new_owner_email_address on the Remove User from Team API call.

Note: This setting is only available on Dropbox Sign Enterprise plans. On other plans, the field may be ignored or the API may return an error on deprovision — leave the field empty if you are not on Enterprise.

How It Works

User Provisioning

When a user is assigned in your IdP:

Scimify checks whether the email already exists as an active team member (across the root team and sub-teams)
If not, Scimify checks for an existing pending invite for that email (root team invites only — see limitations)
If neither exists, Scimify invites the user to the target Dropbox Sign team with the requested role

The invited user must accept the invite before they appear as an active team member in Dropbox Sign.

User Updates

Pending invites — Dropbox Sign does not support updating an invite in place; Scimify cancels the pending invite and sends a new invite when dropboxSign_role or dropboxSign_team_id changes
Active members — role only — the Dropbox Sign API does not expose a role-update endpoint for accepted members; Scimify does not change active members’ roles when only dropboxSign_role is updated (no-op). Change roles manually in Dropbox Sign if needed, or move the user to another team with a new role via dropboxSign_team_id
Active members — team — updating dropboxSign_team_id moves the user to that team (and can apply a role when dropboxSign_role is also sent)
Profile fields — name and email are not updated through this integration

User Deprovisioning

When a user is unassigned or deactivated in your IdP, Scimify removes the user from the Dropbox Sign team (including sub-teams) or cancels a pending invite.

This is a hard remove from the team (not a soft disable in Dropbox Sign).

If Document transfer email is configured and your plan supports it, removed users’ documents are transferred to that account.

Custom SCIM Attribute Configuration

To manage Dropbox Sign roles and sub-team placement from your IdP, configure the following custom attributes.

Attribute: dropboxSign_role

Setting	Value
Type	String
External namespace	`urn:ietf:params:scim:schemas:extension:custom:2.0:User`
Attribute name	`dropboxSign_role`
Description	Dropbox Sign team role for the invited or provisioned user
Default	`Member` (if not sent in SCIM)

Valid values:

Value	Description
`Member`	Standard team member (default)
`Developer`	Developer role (API plan teams)
`Team Manager`	Team manager role
`Admin`	Team administrator

Scimify accepts dropboxSign_role in any of these common SCIM shapes:

Top-level field: dropboxSign_role
Extension key: urn:ietf:params:scim:schemas:extension:custom:2.0:User:dropboxSign_role
Nested extension object: urn:ietf:params:scim:schemas:extension:custom:2.0:User → { "dropboxSign_role": "Developer" }

Attribute: dropboxSign_team_id

Setting	Value
Type	String
External namespace	`urn:ietf:params:scim:schemas:extension:custom:2.0:User`
Attribute name	`dropboxSign_team_id`
Description	Dropbox Sign `team_id` for the root team or a nested sub-team
Default	Root team for the API key (if omitted or empty)

Obtain team IDs from List Teams on the Dropbox Sign instance in Scimify (names and IDs for the root team and nested sub-teams). As an advanced alternative, use the Dropbox Sign List Sub Teams API and walk nested children until you reach the team you want.

Scimify accepts dropboxSign_team_id in the same SCIM shapes as dropboxSign_role (top-level field, flat URN key, or nested extension object).

Suggested Okta profile attributes

In Okta, add user profile attributes for your Dropbox Sign SCIM app:
- Role
  - Display name: Dropbox Sign team role
  - Variable name: e.g. dropboxSignRole
  - Type: string
  - External namespace: urn:ietf:params:scim:schemas:extension:custom:2.0:User
  - External name: dropboxSign_role
- Team
  - Display name: Dropbox Sign team ID
  - Variable name: e.g. dropboxSignTeamId
  - Type: string
  - External namespace: urn:ietf:params:scim:schemas:extension:custom:2.0:User
  - External name: dropboxSign_team_id
Restrict role values to the supported list above (enumerated profile field or lifecycle rule)
Map both attributes in the Okta → Scimify provisioning profile so they are included on create and update
Optionally use Okta group membership rules or attribute mappings to set dropboxSign_team_id from group assignment (for example, map each department group to a specific sub-team ID)

Mapping guidance

Set a sensible default role (typically Member) for standard employees
Use entitlements or group rules to assign Developer, Team Manager, or Admin where appropriate
Role changes on accepted members are not applied by Scimify unless combined with a team move — update roles in Dropbox Sign directly if needed
Leave dropboxSign_team_id unset for users who should remain on the root team
Use List Teams in Scimify to copy the exact team_id when mapping groups or attributes to sub-teams

Limitations and Behavior Notes

Invite-based create — SCIM “create user” invites a team member; users are not fully active until they accept
Single-team membership — a Dropbox Sign account can belong to only one team at a time
Pending invite discovery — Dropbox Sign does not return pending invites for sub-teams on list/refresh APIs after the invite is sent. Scimify preserves pending invite records it created so refresh does not drop them; accepted members on sub-teams are listed normally
Pending invite tracking — Scimify stores invite identifiers until acceptance; lookups reconcile invite vs member IDs on refresh
No group support — this connector does not create or sync groups; use dropboxSign_team_id for sub-team placement
Role updates for active members — only pending invites receive role-only changes via SCIM; active members require a team move (with role) or a manual role update in Dropbox Sign
No profile updates for active members — Dropbox Sign users are individual accounts that join a team; they are not owned by the team. SCIM profile updates (such as name or email) therefore do not apply to active team members
Deprovision removes team membership only — SCIM deprovisioning removes the user from your team (or cancels a pending invite) but does not disable or delete their Dropbox Sign account. The account remains as an individual user. Re-adding or re-inviting the same person rejoins that existing account, so they continue with their current credentials rather than creating a new one
Enterprise document transfer — optional new_owner_email_address only applies on Enterprise plans
API key scope — Dropbox Sign API keys are not scope-restricted; use a dedicated admin key where possible

Troubleshooting

Authentication failed (401)
- Confirm the API key is correct and active in Dropbox Sign API settings
- Regenerate the key and update the Scimify integration config
team_invite_failed
- The user may already belong to another Dropbox Sign team
- Resolve team membership in Dropbox Sign (or move them with dropboxSign_team_id) before reprovisioning
Unknown dropboxSign_team_id
- Confirm the value is a valid team_id from your Dropbox Sign hierarchy (root or nested sub-team)
- Click List Teams on the Dropbox Sign instance in Scimify and copy the exact team_id
- As an advanced alternative, use List Sub Teams starting from the parent team and walk nested children as needed
Invalid dropboxSign_role
- Ensure the value is one of: Member, Developer, Team Manager, Admin
Deprovision failed with document transfer configured
- Confirm your Dropbox Sign plan is Enterprise and the transfer email is an active team member
- Clear Document transfer email if you are not on Enterprise
User not removed after deprovision
- Verify the user was unassigned from the IdP SCIM app and provisioning ran successfully
- Check Scimify audit logs for remove-member operations
Pending sub-team invite missing after refresh
- Dropbox Sign does not expose pending sub-team invites on list APIs; Scimify keeps pending invites it created. After the user accepts, they appear as an active member on that sub-team

Additional Resources

Need Help?

If you encounter issues configuring dropboxSign_role / dropboxSign_team_id mappings, API access, or Enterprise document transfer, contact [email protected] for assistance.