Home Enterprise Governance

Enterprise Governance

By Admin General
4 articles

Audit Logs

Support Portal maintains a continuous, immutable record of administrative and operational activity within each workspace through its Audit Logs capability. Every tracked event captures four dimensions — the identity responsible, the action performed, the timestamp, and the originating network address — providing a structured audit trail that organizations can reference for compliance reporting, internal investigations, and change management oversight. Operational objective Audit Logs address three core governance requirements: - Traceability — Every configuration change, access event, and administrative action is attributed to a specific user identity, timestamp, and source address. When a regulatory body or internal auditor asks "who changed this setting and when?", the answer is recorded and retrievable. - Accountability — By surfacing individual actions against platform resources, Audit Logs discourage unauthorized changes and provide an evidentiary basis for corrective measures when operational policy is violated. - Compliance readiness — Organizations subject to ISO 27001, telecom-sector security mandates, or government information management standards require demonstrable logging of privileged activity. Audit Logs provide this without additional tooling or manual record-keeping. When audit logging matters Audit Logs become operationally critical in environments where multiple administrators manage a shared workspace, where regulatory frameworks mandate change tracking, or where incident response procedures require forensic reconstruction of events. Common scenarios include: | Scenario | Governance value | |---|---| | Regulatory audit | An external auditor requests evidence that administrative access is monitored and recorded. Audit Logs provide a timestamped, identity-attributed trail of every privileged action. | | ISO 27001 certification | Control objectives around access management and change logging are satisfied by the platform's native audit capability, reducing the need for compensating controls. | | Incident investigation | A misconfigured automation rule or inbox routing change causes operational disruption. Audit Logs allow administrators to identify the responsible change, the actor, and the exact time it was applied. | | Change management review | Before promoting configuration changes to production, a governance team reviews recent log entries to confirm that only authorized modifications have been applied. | Accessing Audit Logs Navigate to Settings > Audit Logs to open the activity log interface. The log interface presents entries in reverse chronological order. Each entry displays three data points: | Column | Content | |---|---| | Activity | A structured description of the action, including the actor's name or email and the affected resource. | | Time | The date and timestamp of the event, recorded in the workspace's configured timezone. | | IP Address | The network address from which the action originated, supporting source attribution during investigations. | Use the page navigation controls to move through historical entries. For targeted searches within the visible page, use the browser's built-in search function to locate entries by actor name, resource type, or action keyword. Tracked activities Audit Logs capture events across six operational domains. Each entry follows a consistent format that identifies the actor, the action, and the affected resource. User and access events Authentication and access status changes are logged to support session monitoring and access reviews: - Agent sign-in and sign-out events - Self-initiated availability status changes (online, offline, busy) - Administrator-initiated availability changes applied to another agent - User invitations issued, including the assigned role - Role changes applied to existing agents These entries support periodic access reviews and provide evidence of authentication activity for security audits. Workspace configuration changes Modifications to workspace-level settings are recorded as account activity events. Any update to the workspace configuration — such as changes to general settings, business hours, or display preferences — generates a log entry attributing the modification to the responsible administrator. Automation rule changes Creation, modification, and deletion of automation rules are individually logged with the rule identifier. This is particularly relevant in environments where automation governs conversation routing, assignment, or escalation — changes to these rules can have broad operational impact, and the audit trail provides a mechanism to review what changed, when, and by whom. Macro changes Creation, modification, and deletion of macros are logged with the macro identifier. In organizations where macros standardize agent responses and operational procedures, tracking changes ensures that updates to shared workflows are attributable and reviewable. Inbox configuration changes Inbox-level events include: - Inbox creation, modification, and deletion - Agent additions to or removals from an inbox Because inboxes define the entry points for customer interactions, changes to inbox configuration can affect routing, channel availability, and agent assignment. Logging these events provides visibility into modifications that may affect service continuity. Webhook configuration changes Creation, modification, and deletion of webhook endpoints are logged with the webhook identifier. Webhook configuration controls external system integrations, and unauthorized changes can expose operational data to unintended recipients or disrupt downstream processing. Team membership changes Team-level events include: - Team creation, modification, and deletion - Agent additions to or removals from a team Because teams influence conversation routing and assignment logic, structural changes to team composition have operational implications that should be reviewed and traceable. Governance and compliance considerations Regulatory audit support For organizations operating under formal audit regimes, Audit Logs serve as a primary evidence source for demonstrating operational accountability. During a regulatory examination or certification assessment, auditors typically request evidence that: 1. Privileged administrative actions are logged with actor identity, timestamp, and source. 2. Changes to access control configurations (roles, team assignments, inbox memberships) are recorded. 3. Modifications to automated processes are attributable and timestamped. Audit Logs satisfy these requirements natively within the platform, reducing reliance on external monitoring tools for application-level activity. Periodic review practices Regulatory frameworks and internal governance policies frequently require periodic reviews of administrative activity. Recommended practices include: - Weekly operational review — Scan recent entries for unexpected configuration changes, particularly to automation rules, inbox settings, and webhook endpoints. - Monthly access review — Correlate user access events (invitations, role changes) with current staffing records to identify stale accounts or inappropriate privilege assignments. - Pre-audit preparation — Before a scheduled compliance assessment, export or review relevant log periods to confirm that recorded activity aligns with documented change management procedures. Separation of duties and change attribution In environments that enforce separation of duties, Audit Logs provide independent verification that configuration changes were made by authorized personnel. Cross-referencing log entries against an approved change register allows governance teams to detect unauthorized or undocumented modifications without relying on self-reporting by administrators. Data retention awareness Audit Log retention is subject to the workspace's data retention configuration. Organizations with regulatory obligations around log preservation should verify that retention periods meet or exceed applicable requirements. For long-term archival needs, consider periodic export of log data to an external compliance repository. See Data Retention for retention policy configuration. Related capabilities - Custom Roles — Define granular permission sets to control who can perform the administrative actions that Audit Logs track. Changes to role definitions and assignments are themselves logged. - Automation — Automation rule modifications are captured in the audit trail. Review log entries after rule changes to confirm expected behavior. - Teams — Team creation, membership changes, and deletions are tracked. Cross-reference team logs with assignment logic to investigate routing changes.

Last updated on Feb 25, 2026

Cookie Usage and Compliance

Overview Support Portal uses a limited set of cookies to maintain session state and ensure consistent operation of the platform. This document provides a comprehensive inventory of all cookies set by the platform, their purposes, retention characteristics, and relevance to data privacy regulations including GDPR, CCPA, and sector-specific compliance frameworks. Operational Objective Review the cookie inventory below to inform your organization's privacy policy, cookie consent implementation, and regulatory compliance documentation. Organizations operating under GDPR, CCPA, or equivalent data protection regulations should incorporate this information into their data processing records. Chat Widget Cookies The following cookies are set in the browser of end-users who interact with the customer-facing live chat widget: | Cookie Name | Purpose | Classification | |---|---|---| | cw_conversation | Maintains conversation continuity as the contact navigates between pages or returns to the website in a subsequent session. Ensures the conversation thread is preserved without requiring the contact to re-identify. | Strictly necessary | | cw_user_{identifier} | Caches contact identity data when a contact has been identified through the SDK setUser method. The {identifier} portion corresponds to the unique contact identifier provided during identification. | Strictly necessary | Operator Dashboard Cookies The following cookies are set in the browser of operators and administrators accessing the Support Portal dashboard: | Cookie Name | Purpose | Classification | |---|---|---| | _supportportal_session | Maintains the authenticated session for the Super Admin panel. Required for administrative access persistence across page navigations. | Strictly necessary | | cw_d_session_info | Maintains the authenticated session for the operator dashboard. Stores session metadata for the currently authenticated operator. | Strictly necessary | Privacy and Compliance Considerations All cookies used by Support Portal are classified as strictly necessary for the functional operation of the platform. They do not track user behavior for analytics, advertising, or profiling purposes. Key compliance characteristics: - No third-party tracking: Support Portal does not set cookies for advertising networks, behavioral analytics, or cross-site tracking. - Session-scoped data: Dashboard session cookies expire when the authenticated session ends or upon explicit sign-out. - Data minimization: Only the minimum data required for session persistence and contact continuity is stored in cookies. - Self-hosted control: Organizations operating self-hosted deployments retain full control over cookie domain configuration and retention policies at the infrastructure level. Governance Recommendation For organizations subject to GDPR, CCPA, or industry-specific data protection requirements (such as telecommunications regulations or government data handling standards), the cookies listed above should be documented in your: - Cookie policy and consent notices. - Data processing records (GDPR Article 30). - Privacy impact assessments where applicable. Since all Support Portal cookies are strictly necessary for platform operation, they typically fall under the exemption from explicit consent requirements under GDPR. However, transparency obligations still apply, and these cookies should be disclosed in your public-facing cookie policy.

Last updated on Feb 25, 2026

Required Conversation Attributes

Support Portal allows workspace administrators to designate specific custom attributes as mandatory for conversation resolution. When required attributes are configured, agents cannot resolve a conversation until every designated field contains a value — ensuring that structured operational data is captured consistently across every interaction, regardless of volume or agent turnover. Operational objective Required conversation attributes address a persistent data quality challenge: agents resolving conversations without recording the structured metadata that downstream processes depend on. In high-volume environments, this omission degrades reporting accuracy, complicates root-cause analysis, and undermines compliance reporting. Enforcing attribute completion at the point of resolution serves three governance functions: - Data completeness — Every resolved conversation carries the metadata your organization needs for classification, trending, and audit. There are no gaps to backfill after the fact. - Process standardization — Agents follow a uniform data capture protocol regardless of team, shift, or inbox. This eliminates inconsistency between individuals or departments in how conversations are categorized. - Regulatory traceability — In environments where incident classification or service categorization is mandated — telecom fault management, government citizen service desks, regulated financial operations — required attributes provide a mechanism to enforce and demonstrate compliance with those mandates. Enterprise scenarios | Scenario | Required attribute example | |---|---| | Telecom fault management | A Fault Category list attribute (e.g., Network Outage, Billing Dispute, Service Activation) ensures every resolved ticket is classified for regulatory reporting to the national communications authority. | | Government citizen services | An Incident Type attribute with standardized categories allows the agency to produce quarterly service reports and track resolution patterns across departments. | | Financial services | A Complaint Classification attribute aligned to the regulator's taxonomy enables accurate complaint reporting and trend analysis. | | Internal IT operations | A Root Cause text attribute captures diagnostic information at resolution, feeding into problem management workflows and knowledge base improvements. | How enforcement works Required attribute enforcement activates at the point of resolution. When an agent attempts to resolve a conversation — either individually or as part of a bulk operation — the platform evaluates whether all designated attributes have values. If every required attribute already contains a value (populated earlier during the conversation, set via automation, or applied through the conversation sidebar), resolution proceeds without interruption. If one or more required attributes are missing, the platform presents a completion interface listing every unfilled mandatory field. The agent must provide values for all listed attributes before resolution can proceed. There is no option to bypass or defer — the conversation remains in its current state until the data capture requirements are satisfied. This enforcement model is intentionally strict: it ensures that data quality controls cannot be circumvented by agents under time pressure or during high-volume periods. Configuring required attributes Configuration is restricted to administrators and is managed at the workspace level. All conversations across every inbox in the workspace are subject to the same required attribute set. To configure enforcement, navigate to Settings > Conversation Workflows and locate the Attributes required on resolution section. Select Add Attributes to open a selector listing all conversation-level custom attributes defined in the workspace. Choose one or more attributes from the selector. Each selected attribute is immediately enforced — agents will be required to provide a value for these fields before resolving any conversation going forward. No additional save step is necessary; the enforcement takes effect as soon as attributes are added to the list. To remove an attribute from the required list, select the delete icon next to it in the configuration interface. Removing an attribute from the required list does not delete the attribute itself or clear any values already recorded on conversations — it only removes the enforcement constraint. Prerequisites Required attributes draw from the pool of conversation-level custom attributes defined in your workspace. Before configuring enforcement, ensure the attributes you intend to require have been created and appropriately typed. See Custom Attributes for guidance on defining custom attributes, including supported data types and naming conventions. Only conversation-level attributes can be designated as required. Contact-level attributes are not eligible for resolution enforcement, as they describe the contact rather than the interaction. Agent experience during resolution When an agent selects Resolve on a conversation that is missing one or more required attribute values, the platform presents a completion interface listing every unfilled mandatory field. Each field renders with the appropriate input control for its data type — a text field for text attributes, a date picker for date attributes, a dropdown for list attributes, and so on. The agent provides values for each listed attribute and then selects Resolve conversation to simultaneously save the attribute values and complete the resolution. If the agent is not ready to resolve, they can dismiss the interface and return to the conversation without changes. This interaction is designed to be lightweight. Agents who populate required attributes earlier in the conversation — through the sidebar attribute panel or via automated rules — will not encounter the completion interface at all. The enforcement prompt only appears when gaps exist. Supported attribute types Any conversation-level custom attribute can be designated as required. The following data types are supported, each with its corresponding input control at the resolution prompt: | Attribute type | Input behavior | |---|---| | Text | Free-form text entry | | Number | Numeric input with validation | | Link | URL input with format validation | | Date | Date picker control | | List | Dropdown selection from predefined values | | Checkbox | Binary yes/no selection | For attributes where classification consistency is critical — such as fault categories or incident types — the List type is recommended. Predefined options eliminate free-text variation and produce cleaner data for reporting and analysis. Bulk resolution behavior When agents perform bulk resolution on multiple conversations simultaneously, required attribute enforcement applies to each conversation individually. Conversations that already satisfy all required attributes are resolved normally. Conversations with missing values are excluded from the bulk operation, and the platform notifies the agent which conversations could not be resolved and why. This prevents bulk operations from bypassing data quality controls. Agents must address the missing attributes on excluded conversations individually before those conversations can be resolved. Operational considerations - Administrator-only configuration — Only administrators can add or remove attributes from the required list. Agents and custom roles without administrative access cannot modify enforcement settings. - Manual resolution scope — Required attribute enforcement applies to manual resolution actions (individual and bulk). Resolution triggered through the API does not enforce the attribute check, allowing automated workflows to resolve conversations programmatically where appropriate. Organizations that use API-based resolution should implement equivalent data validation in their integration logic if attribute completeness is a requirement. - Attribute deletion handling — If a custom attribute definition is deleted from the workspace, it is automatically removed from the required list. No manual cleanup is necessary. - No inbox-level granularity — Required attributes are configured at the workspace level and apply uniformly to all inboxes. If different inboxes require different mandatory fields, consider using Automation to pre-populate attributes based on inbox context, or coordinate with your workspace architecture to separate distinct operational domains. Governance and compliance considerations Data quality as a governance control In regulated environments, the completeness and consistency of operational data is not optional — it is a compliance obligation. Telecom operators reporting service disruptions to national regulators, government agencies producing citizen service metrics, and financial institutions classifying customer complaints all depend on structured, complete data attached to every interaction. Required conversation attributes transform data capture from a best-effort practice into an enforced control. By making attribute completion a prerequisite for resolution, the platform ensures that the data feeding downstream reports, audits, and regulatory filings is complete by design rather than by discipline alone. Alignment with reporting and audit requirements Required attributes work in concert with the platform's reporting capabilities. When every resolved conversation carries a consistent set of classification metadata, reports built on that data are reliable without manual correction or gap-filling. This is particularly relevant for: - Periodic regulatory filings where completeness is a submission requirement - Internal quality audits where data gaps trigger non-conformance findings - Trend analysis where inconsistent categorization produces misleading results Periodic review Review your required attribute configuration periodically to ensure it remains aligned with current operational and regulatory needs. As reporting requirements evolve or new compliance mandates take effect, the required attribute set may need to expand or adjust. Conversely, removing attributes that are no longer operationally relevant reduces unnecessary agent friction without compromising data quality. Related capabilities - Custom Attributes — Define the custom attributes that can be designated as required. Attribute types, naming, and configuration are managed separately from enforcement. - Automation — Configure operational rules that pre-populate attribute values based on conversation context, reducing the frequency with which agents encounter the resolution prompt. - Reports — Access reporting interfaces that consume the structured data captured through required attributes. - Custom Roles — Control which agents have administrative access to configure required attributes and other governance settings.

Last updated on Feb 25, 2026

AI & Platform Abuse Prevention

Support Portal by Altores implements a layered abuse prevention model that addresses distinct classes of platform misuse across multiple system layers. Controls are applied independently at the infrastructure level, the application layer, the AI execution pipeline, and the client account level, ensuring that protections remain effective regardless of the channel or access pattern involved. 1. Web traffic protection Relevant public-facing HTTP endpoints are protected by request throttling applied per client IP address. These controls mitigate brute-force attacks, automated scraping, and denial-of-service attempts against the platform. | Endpoint category | Protection applied | |---|---| | Global requests | IP-based rate limiting across all relevant public endpoints | | Widget interactions | Limits on conversation creation, session creation, and contact updates | | Authentication | Rate limits applied to login attempts, password resets, account registration, and MFA verification | | File uploads | Request limits protecting storage and bandwidth resources | | Transcript export | Limits preventing excessive data extraction | | Contact search | Limits preventing automated scraping | | Reporting endpoints | Request limits protecting analytical workloads | All limits are configurable through configuration settings at the account-level and at platform level by direct request to the Altores Team. Trusted IP addresses may be safelisted where appropriate (for example, for internal networks or monitoring services). Throttle events are logged with relevant request metadata to support operational monitoring and security auditing. 2. Messaging channel protection For messaging channels such as WhatsApp, inbound traffic is received through provider webhooks. Because the originating IP address belongs to the provider infrastructure rather than the end user, IP-based throttling is not applicable for per-user abuse prevention in these channels. Rate limiting is instead enforced at the application layer using internal identifiers, specifically contact ID, conversation ID, and AgentBot identifier. Contact-level and conversation-level AI rate limits Before an automated AI response is generated, the system evaluates whether the contact or conversation has exceeded configured activity thresholds. If the configured limit is reached, automated responses are temporarily suppressed and the user receives a feedback message indicating that requests should be retried later. This prevents individual users from repeatedly triggering automated responses at an excessive rate, regardless of the channel they are communicating through. 3. AI agent execution layer In addition to application-level protections, rate limiting is enforced within the AI agent execution layer responsible for generating automated responses. Per-bot rate limiting Each AI bot can be configured with activity limits governing how frequently it processes requests across users and conversations. When these thresholds are exceeded, the system temporarily rejects additional automated response requests and returns a configurable feedback message to the affected user. This protects the AI execution pipeline from excessive request volume originating from any single bot assignment. Client-level AI response quota Each client account is allocated a defined allowance of automated AI responses within a billing period per their contract. The system tracks: - Allocated response capacity - Consumed automated responses - Remaining capacity When the included allocation is reached, usage transitions to pay-as-you-go billing by default, allowing automated responses to continue without service interruption. Alternatively, if requested by the client, automated responses can be configured to pause once the allocation is fully consumed. This provides transparent usage tracking and ensures fair resource allocation across client tenants. 4. Configuration All protections described in this article are configurable within predefined safe ranges through configuration settings in Support Portal or by direct request to Altores. Specific limit values and thresholds are agreed upon at the account level. 5. Layered abuse prevention model Each protection layer operates independently and addresses a distinct part of the system: | Layer | Scope | What it protects against | |---|---|---| | IP protection | Public HTTP endpoints | Infrastructure abuse, brute-force, scraping | | Contact-level AI limits | Messaging channels (per contact / conversation) | Repeated automated response triggering by individual users | | Conversation flood protection | Conversation level | Message spam within individual conversations | | AI bot execution limits | AI processing pipeline | Excessive request volume per bot | | Client-level usage quotas | Account level | Unfair consumption of automated response capacity across tenants | Together, these layers provide a model that protects the platform while maintaining reliable service for legitimate users. No single protection is expected to operate in isolation, the combination of controls is designed to address the full range of abuse vectors relevant to a multi-tenant conversational operations platform.

Last updated on Mar 06, 2026