What is a Developer Managed Service Account?

For developers building applications using data connection components we recommend leveraging the new Developer Managed Service Accounts (DMSA) feature as a streamlined approach to providing Procore administrators the ability to easily install and provision data connection applications in their company accounts. The DMSA feature allows developers to specify the exact company and project level tool permissions that are required for their application to run properly on the Procore platform. Company administrators define which projects the application can access using those permissions. Developers utilize DMSAs to provide a more convenient and secure alternative to traditional service accounts. Company administrators benefit from DMSAs through improved application management and better visibility into application usage.

 Sunset of Traditional Service Accounts

All Traditional Service Accounts will sunset on March 24, 2025.

Traditional Service Accounts were deprecated on December 9, 2021. Beginning January 21, 2025, we will no longer allow the creation of new Traditional Service Accounts. Existing Traditional Service Accounts will continue to function until March 24, 2025.

In accordance with this timeline, developers of data connection applications that currently use Traditional Service Accounts are required to update their applications to use Developer Managed Service Accounts, and customers will be required to install these updated applications before the sunset date. All data connection applications not migrated by the sunset date will cease to function. Any application listed on the Procore App Marketplace that is not using a supported method for accessing the Procore API will be removed by the sunset date. See Migrating Data Connection Applications to Use DMSAs for additional information.

Benefits of Using Developer Managed Service Accounts (DMSAs)

There are a number of benefits to be gained by using DMSAs over traditional service accounts:

Risks Associated with Traditional Service Accounts

Installing and using applications that utilize traditional service accounts comes with the following risks:

How does a DMSA differ from a traditional service account?

Here are some of the primary differences between DMSAs and traditional service accounts.

  Developer Managed Service Account Traditional Service Account
Account Creation
  • A directory user associated with the DMSA is automatically created in the Company and/or Project Directory tool.
  • A traditional service account must be created and managed manually by a company administrator.
Authorization
  • A single set of credentials (client_id, client_secret) is used to access all companies where the application is installed.
  • Each service account created in a company by an administrator has a unique set of credentials, requiring manual coordination with the developer for successful integration.
Permissions
  • Required permissions are defined by the developer in the application manifest and automatically applied during installation.
  • Permissions for each service account must be configured manually by a company administrator.
Project Configuration
  • During installation, you can select which projects the DMSA application is allowed to run in. Once the application is installed, you can add or remove permitted projects as needed.
  • Project access and must be configured and managed manually by the company administrator.
App Management
  • DMSA-enabled applications are easily installed from the App Marketplace or as a custom install. Company Admin tool (App Management) used for uninstall/reinstall.
  • All aspects of traditional service account installation and management must be handled manually by a company administrator.

What will I see in my account after installing an application that uses a DMSA?

During the installation process, a new user record may be created in the Company and/or Project Directory tool that represents the DMSA. The DMSA contact name follows a distinct format with the application name converted to lower case and separated by dashes followed by an eight-character randomly generated id. For example, installing the application My DMSA Test App would create the user my-dmsa-test-app-469b1f7f in the Company Directory. It is important that you do not  edit or delete directory users created by DMSA application installations as this may cause problems with the operation of the application.

Best Practices for DMSA Permissions Management

Managing permissions for a Developer Managed Service Account (DMSA) involves careful consideration to ensure application functionality and account security. Below are best practices and important considerations for managing permissions effectively.

  1. Use the Permissions Tab for Project Membership - To manage DMSA project access, including adding or removing project memberships, utilize the Permissions tab within the app under App Management. This option is available to Company Administrators.

  2. Permissions Reconfiguration on App Update or Reinstall - Each time an app is updated or reinstalled, Company Administrators must reconfigure the list of permitted projects. Future projects requiring DMSA access must also be manually added to the permitted list.

  3. Using the Directory Tool for Permissions Templates - Some administrators use the Directory tool with a permissions template to streamline DMSA management:

    • Enabling the “Add [DMSA user] to all new projects” checkbox can simplify permissions by automatically adding the DMSA user to future projects.
    • Important Note: When an app is updated or reinstalled, permissions defined in the app’s manifest do not automatically transfer to the permissions template in the Directory tool, potentially affecting app functionality. This misalignment should be manually reconciled.
  4. Avoid Manual Updates to DMSA Permissions - Manually adjusting DMSA permissions within the Directory tool is generally discouraged, as it can lead to inconsistencies and complicate account management.

  5. Limit DMSA Access to Company-Level Directory Tool - Avoid granting admin-level access to the Company-level Directory tool for the DMSA user. This level of access permits changes across multiple projects and tools in your Procore account, which could impact your organization’s workflows. Only allow this level of access if absolutely necessary for the integration and ensure you thoroughly understand the implications.

Understanding Procore API Authentication

Applications built on the Procore platform use the industry standard OAuth 2.0 Authorization Framework for authentication with the API. The Procore API supports the following two authorization grant types, or authentication flows:

Procore company administrators are ultimately responsible for managing the permissions of their directory users regardless of the authorization grant type used by an integration - authorization_code (logged in user's permissions) or client_credentials (service account/DMSA permissions).

Shared Responsibility Security Model

As a Software as a Service (SaaS) provider, Procore follows a shared responsibility model in the context of platform security.

See Also