Public website channels are not a place to exchange credentials or sensitive production information. This applies to the Help Centre, contact form, and SalesIQ support messaging, even when the information seems necessary to explain a problem.
Do not submit sensitive information
- Passwords or one-time codes
- API tokens, OAuth secrets, or session values
- Private keys, certificates, or connection strings
- Payment-card or banking information
- Confidential customer, employee, or supplier records
- Regulated, health, identity, or other sensitive personal data
- Production configuration containing secrets or internal access details
- Database exports, logs, or screenshots that contain protected values
A URL, field name, error reference, approximate timestamp, and plain-language description are usually enough for the first conversation. If a screenshot or example is helpful, redact names, email addresses, identifiers, tokens, account numbers, and confidential business data before sending it.
How access is arranged for approved work
If an approved engagement requires system access, the method is agreed separately from the public enquiry. The arrangement should identify the systems, permitted actions, responsible people, duration, storage expectations, and process for changing or removing access.
Access should use named accounts and least-privilege permissions where the system supports them. Shared administrator credentials should not be treated as the default way to begin work. Customer policies and platform capabilities may require additional approval or a different access pattern.
Separate environments and controlled data
A non-production environment and representative test data are preferable when available. They allow interfaces, mappings, permissions, and failure behavior to be checked without exposing live records or disrupting operational work.
When production interaction is necessary, the applicable scope, safeguards, logging, change approval, and rollback approach should be understood before the activity. The exact controls depend on the system and the agreed engagement; this public article does not replace customer security policy.
Logging and observability
Operational logs should help diagnose workflow behavior without copying secrets or unnecessary personal data. Authentication values, request bodies, and upstream error responses may contain protected information and should not be recorded indiscriminately.
Monitoring should identify that a workflow failed, where it failed, and what action is needed while minimizing the sensitive information displayed to operators.
Review and remove access
Access should be reviewed when responsibilities or scope change. At handover or the end of an engagement, temporary permissions, service accounts, secrets, and approved access paths should be removed or transferred according to the agreed ownership model.
If a credential is shared accidentally
Stop using the affected public channel and notify the appropriate system owner through an established secure route. The owner should assess whether the credential must be revoked or rotated according to the relevant platform and organizational process. Do not repeat the credential in a follow-up message.
Celes7a cannot use a Help Centre article to define every customer security procedure. Engagement-specific access, retention, incident, and compliance requirements must be agreed before protected information or production access is introduced.
Questions about a proposed access method can be discussed without sending the actual secret. Describe the platform, identity type, required operation, and customer policy constraints, and Celes7a can help identify what must be agreed next.
Read the support-messaging privacy notice