Project access · Keep the handoff clear

The right access.
For the work you’ve requested.

Use the form below when XMLA asks for access details for your project or support request. Include the relevant context and follow the guidance below so the team can connect the information to the right work.

27 years in business. A thoughtful approach to your website and accounts.

Illustrative project-access-handoff scene for XMLA website services

Secure Form

Submit the requested access details.

Please reference the project, ticket, request, site, or service this access is related to. Use temporary or role-based access whenever available.

1Confirm XMLA requested the access before submitting credentials.
2Provide only credentials connected to the active request.
3Notify XMLA after credentials are changed, revoked, or replaced.

Do not submit unrelated third-party accounts, banking credentials, payment method passwords, or personal accounts that are not required for the approved XMLA request.

Before You Submit

Context matters as much as the credentials.

Clear authorization and account details help XMLA use the right login path without guessing across hosts, registrars, applications, and support requests.

Required

Access scope

Only send credentials or access details that XMLA needs for the active request.

Required

Account context

Include the site, host, registrar, mailbox, platform, or service tied to the access.

Required

Authorization

Identify the account holder or approved contact authorizing XMLA to use the access.

Required

Expiration plan

Rotate, revoke, or update temporary access after the work is complete.

Access Types

Use one intake path for the systems behind your website.

Website work often touches more than a WordPress login. Include the platform, host, domain, DNS, email, or connected app details that apply to the request.

CMS

Website Admin

WordPress, WooCommerce, page builder, plugin, and content management access.

Host

Hosting / SFTP

cPanel, SFTP, file manager, database, backup, or server-level access paths.

DNS

Domain / DNS

Registrar, DNS zone, nameservers, SSL validation, MX, SPF, DKIM, and DMARC records.

Apps

Email / Apps

Mailbox, SMTP, IMAP, API, CRM, analytics, automation, or connected-service access.

How XMLA Handles It

A defined path keeps access limited and accountable.

The goal is to collect only what is needed, use it for the active work, verify the result, and close the loop cleanly.

01

Submit

Send details through the secure form with context and authorization.

02

Review

XMLA checks the access path against the support, migration, repair, or project need.

03

Use

Access is used only for the active approved work and related verification.

04

Close

Rotate passwords, remove temporary users, or confirm ongoing managed access.

Security Reminder

Temporary access is usually the best access.

Create limited users where possible, avoid sharing unrelated credentials, and rotate or revoke access after XMLA confirms the work is complete.