Create a separate MySQL login for an application or team member from the service’s Database Users page. Adding a login and granting application-specific database permissions are separate decisions.

Open the intended service

Sign in to the client area, open the intended MySQL service and choose Manage. Use that service’s module tabs for the sections below. Confirm the service and resource before making a change. Enable the corresponding client feature on the intended offering. If a section is missing or unavailable, review that service’s configuration rather than trying a different service.

Choose the login

Open Database Users, or Manage users from the overview. Review existing names first so you do not submit a duplicate while an earlier operation is still pending.

The module accepts usernames that begin with a letter and contain letters, numbers and underscores, from 2 to 32 characters. Reserved system names are not available. Choose a recognisable application name rather than using the administrator login for every application.

Add the user

1. Enter the intended username in the username field.
2. Enter a unique password in the password field. The module’s minimum is eight characters; use a strong password appropriate for the service.
3. Store the password using your approved credential process before submitting. This page does not provide a later reveal control for that additional user’s password.
4. Choose Add user, then wait and confirm the actual resulting user before trying again.

The module creates MySQL users with the database host value %. This does not open the network allow-list: the application’s source still needs the intended Trusted Sources entry. The page lists names without a separate host selector.

Review the application’s permissions

Have the database administrator review and apply the permissions needed for the intended application database. The module’s Add user control is not a database-specific grant editor and does not demonstrate that a new login has least privilege.

Use the new login, actual application database, correct network source and TLS verification in the application’s connection settings. Verify both the access it needs and the permissions it should not have before treating configuration as complete.

Check the outcome

Wait for the provider operation to settle, then reload the relevant section and verify the actual result. A success notice or Done activity row can precede final provider completion. If an operation is already in progress, wait rather than repeatedly submitting it.

An empty list can also result from a failed read; it does not establish that the resource has no entries. For an uncertain result, reconcile the service and provider state before repeating a change. Do not include passwords, provider keys or full customer records.

See the PD Google Cloud MySQL Blesta guide for related setup, or explore PD Google Cloud MySQL.