1. CPQ
  2. Databases
  3. Database Logins

Database Logins

Article last updated:

Optionally, you can define individual database logins to grant granular control to specific database tables, and to specific actions on those tables. In this way, you can delegate the responsibility for maintaining a table to non-administrators, without sacrificing too much control.

Database Logins

You and your colleague CPQ administrators can decide how you want to manage your company's CPQ database resources. Start simple, with one master login to manage all database resources. Then, as your use of databases grows and you want to have more granular control over who can do what to each database table, you can begin using your own custom database logins.

We use the term "login" instead of "user" to clearly separate a database login credential from a CPQ user credential. They are completely separate. For example, a database login can be used by a non-CPQ administrator. A database login can be used by multiple people.

One Standard Master Login: "xuser"

This master username and password has access to all database tables in one environment (Dev, Test, or Production). This login cannot be changed or deleted. Many companies only use this master database login to perform their work, and don't create any custom logins.

Finding the "xuser" login

Any CPQ administrator can gather this information:

  1. As a CPQ administrator, login to the environment where you want to manage databases (either Dev, Test, or Production).
  2. Browse to Infrastructure > Database Firewall.
  3. Click the button "Send DB xuser Credentials". If database tables have already been activated for your org, then an email will be sent to you that includes the names of the dev, test, and prod databases for your org.

If you are using the preview site to test upcoming new features, credentials are different. Logon to the preview site first before finding and clicking that button to receive the connection information specific to the preview site.

Unable to connect with the login info that was emailed to you? Ensure your workstation IP address is included in both the CPQ and your own company firewall rules.

Many Custom Limited Logins

If you want to offer more limited control, you can create as many custom logins as required. For example, consider an "ItemMaster" database table needed by your configurators. It must be made available to different colleagues for different purposes, so create a custom login for each:

  • Create an "integration robot" login with full read-write access to the table (but no schema-changing rights). This could be used by the ETL tool that updates the table nightly from your ERP system.
  • Create a "auditor" login with read-only access for your auditing team to use for a short week-long project, and delete the login at the end of the project.
  • Share the login credentials, along with instructions to connect to your database with common free tools such as Azure Data Studio or Microsoft MSSMS. Your integration and auditors can perform their tasks securely, with no direct access to the Epicor CPQ administration interface.

Creating/Editing a Custom Database Login

  1. Start with a clear goal for this login.
    You may use a name that helps express this goal by either the intended user (such as "Marketing"), or the rights of the login (such as "ItemMaster-Auditor")
  2. As a CPQ administrator, browse to Databases > Database Users.
    • Click New to create a new login.
    • Browse the list and click on an entry to edit an existing login.
  3. The login entry appears. Set the Name and Password. The password should be at least 10 characters long, with at least 3 mixed lower, upper, numeric, and symbol characters.
  4. If you want this user to see the read-only technical tables which describe your CPQ environment, grant access to the dbo schema tables. Usually, this is left off.
  5. If you want this user to have full rights to not only change the data, but also change the structure of the tables by adding or removing columns, then grant all x schema permissions. Usually, this is left off.
  6. In the list of tables that follow, select the rights this login should have for each table:
    • Read the data in all columns of the table. If this is checked, then any of these other rights can also be checked.
    • Insert new rows of data into the table.
    • Update (edit) existing rows of data in the table.
    • Delete existing rows of data in the table.
    • Alter the schema (structure) of the table itself by adding or removing columns.
  7. Click Save at the bottom of the screen.
  8. Test the login by using either Azure Data Studio or Microsoft MSSMS to test the login, ensuring that you can only perform the actions you've specified.
  9. Share the database name, along with the login credentials you just created, with the proper person. Note that you may need to add their IP address to the firewall.
Was this article helpful?