Platform Settings

Overview

Platform Settings lives under Administration - Platform Settings and controls how the platform behaves for everyone in the workspace. These are tenant-wide switches; individual per-user preferences (such as interface language) are set separately in the user profile.

Portal Header Name and Logo

Set the name shown in the portal header and upload a custom logo (PNG, JPG, SVG, or WebP, up to 2 MB). The logo also appears on the login page for your workspace, so end-users see your branding from the very first screen.

Self-registration

Toggle whether end-users can sign up for their own portal account using their email address. Self-registered users land in the default Portal Users group with read/submit rights only - they have no access to the management interface. Leave this off to keep the portal invite-only.

Portal Sections

Coarse-grained switches that hide entire modules from all portal users regardless of their permissions. Use them when your workspace does not use a particular module at all:

• Tickets - allow end-users to submit and track incidents and change requests.
• Issues - show issues assigned to the user for remediation.
• Control Tests - allow assigned testers to view and complete control tests.

System Language

Choose the language (English or Dutch) that the system uses when it posts automatic updates on your items. System updates are written once at the moment they happen, so the setting applies to:

• Status-change notes on tickets and issues (for example, "Status changed from open to resolved").
• Attachment events on tickets and issues ("Attachment uploaded: report.pdf").
• Auto-generated issues created from a failed control test.
• Reporter, assignee, and other field-change entries in the comment timeline.

This setting does not change the language that individual users see in the interface. Each user can still pick their own interface language and email-notification language from their profile. System comments already in the database keep the language they were written in.

Email Replies

When a user receives a ticket or issue notification, they can reply directly to the email and Anzen turns the reply into a comment on the same item. Toggle this off to enforce that activity stays in-app (useful for compliance reasons). With the toggle in either state:

• Outbound notifications still go out as normal.
• When on, every notification carries a per-recipient Reply-To address pointing at our inbound mailbox, plus a hint line in the email body so recipients know they can reply.
• When off, the Reply-To header and hint line are omitted, and any reply that still arrives is rejected at the inbound endpoint.
• Successful inbound replies generate a short confirmation email back to the sender so a silent backend failure can't be mistaken for a delivered comment.

Request Categories

Define the options users see in the "What do you need help with?" dropdown when they submit a ticket from the portal. Each category has a label, a ticket type (incident or change), and an optional short description. Admins can reset to defaults at any time, and when no categories are configured the portal falls back to a generic incident/change chooser.