Global Settings

Name and Contact Address

Two short settings that appear in more places than expected.

Where to find it

Architect Panel → Configuration:

• Site Settings — the option groups, grouped by subject

Architect Panel → Integration & Connections:

• E-mail Accounts — what mail is actually sent from

The website title

Used in page titles, in browser tabs, in push notification headings, in e-mail subjects and templates, and in anything that identifies the installation to a user.

So it is not a decorative field. Setting it to "ActiveManage" on an installation your customers know by another name is a small, constant source of confusion.

Keep it short

It is prefixed or suffixed onto page titles and truncated in browser tabs and notification headings. Your organisation’s working name is usually right; its full legal name usually is not.

The author e-mail address

The site’s contact address. It is what a technically curious visitor finds, what some automated systems use, and occasionally what appears in generated content.

Use a role address, monitored

Not a person’s. People leave, and an address that bounces is worse than none — it is a broken contact route that looks like a working one.

And it should be monitored. An address nobody reads means somebody trying to report a problem, a vulnerability or a data-protection concern reaches nobody.

It is not the sending address

Worth being clear about. Outgoing mail is sent from configured e-mail accounts, not from this setting. Changing it does not change what your notifications come from.

Check both after installation

These are exactly the settings left at their defaults during setup and never revisited, because nothing breaks. Look at a page title and a notification to confirm what your users actually see.

Multi-tenant installations differ

Where tenants should present as themselves, the identity a customer sees comes from their tenant rather than from this global setting. Check what a tenant’s users see rather than assuming the global title applies.

Say something meaningful

The title is the name of the thing your users are in. "Portal" tells them nothing; "Northfield Housing Portal" tells them where they are, which matters when they have several such systems.

Worked example

An organisation set its site title to its trading name and its author address to a monitored role account. A check of the actual page title and a test notification found the default title still appearing in push notifications, which was corrected before launch.

Recommendations

• Short, recognisable title — it is truncated everywhere.
• A monitored role address, never a person’s.
• Check a real page title and notification.
• Remember it is not the sending address.

Copyright Line

Two settings control the copyright line shown in the footer: the text, and the address it links to.

Where to find it

Architect Panel → Configuration:

• Site Settings — the option groups, grouped by subject

Architect Panel → Layout & Pages:

• Page Builder — the footer itself

Get the name right

The copyright should name the legal entity that owns the site — your registered company name, not a trading name or a product name. It is a legal statement, and naming the wrong entity makes it a weaker one.

The year

A single current year is conventional. A range from first publication is also fine. What looks careless is a year that has not been updated, because it is the most visible possible sign that a site is not maintained.

If your text is static, put updating it in a January routine.

The link

Usually to your own site, occasionally to a terms or legal page. Point it somewhere that exists and check it after any restructuring — a broken link in the footer of every page is a poor look.

The footer needs more than copyright

Depending on where you operate and what you do, a footer commonly needs to carry:

• A privacy notice link.
• A cookie or consent preferences link.
• Terms of use.
• Company registration details, for a UK limited company.
• An accessibility statement, for public sector bodies.

The copyright setting is one line of that. Do not let it stand in for the rest.

Company details are a legal requirement

A UK limited company must show its registered name, number and registered office address on its website. That is not optional and it is regularly missed.

Consent preferences must be reachable

If you use a consent banner, people must be able to change their mind afterwards. A footer link is the conventional place, and its absence is a common finding.

Check it on a phone

Footers are where content is squeezed hardest on small screens. Links that overlap or wrap badly are still links people are entitled to use.

Keep it short

A footer is not a place for a paragraph. One line of copyright, a short row of links, and the legally required details.

Worked example

An organisation sets its copyright to its registered company name with a rolling year, links it to its own site, and carries privacy, terms, cookie preferences, accessibility and company registration details alongside. The footer is checked on a phone after any layout change.

Recommendations

• Name the legal entity, not the product.
• Update the year — a stale one is very visible.
• Carry the required details, not just copyright.
• Make consent preferences reachable from the footer.

Character Set

The character set decides which characters your database can store. The default is the one you want.

Where to find it

Architect Panel → Configuration:

• Site Settings — the option groups, grouped by subject

Architect Panel → Integration & Connections:

• Database Hosts — the databases themselves

What the default gives you

Full Unicode: every accented character, every non-Latin script, and emoji. It handles anything a user can type, which is the only safe assumption once real people are entering data.

The older four-byte problem

An older, narrower Unicode encoding shares almost the same name and covers most characters — but not emoji and not some less common ones. Text containing them is either rejected or truncated at the first one.

The symptom is characteristic: a record that saves fine until somebody puts an emoji in a note, then fails or silently loses everything after it.

Do not change it without a reason

It is set at installation and it is correct. Changing it on a database with data is a migration, not a setting — every text column has to be converted, and a conversion that goes wrong corrupts text in ways that are hard to detect and harder to reverse.

Symptoms of a mismatch

• Accented characters appearing as question marks or as pairs of odd symbols.
• Text truncated at the first emoji.
• Names that display correctly in one place and wrongly in another.
• Sorting that puts accented characters in surprising positions.

It has to match at every layer

Database, table, column and connection. A correct database with a mismatched connection produces exactly the same symptoms, and that is the layer most often wrong.

External data is where problems arrive

Imports, integrations and files brought in from elsewhere carry their own encodings. Data that looks corrupted after an import is usually an encoding mismatch at the point of import rather than a database problem.

Test with real names

Not with "test". Enter a name with an accent, a name in a non-Latin script, and something containing an emoji, and confirm each stores and displays correctly.

People’s names are not ASCII, and a system that mangles somebody’s name is telling them something.

Get it right before there is data

The whole point. This is a decision that is trivial at installation and a project afterwards.

Worked example

An organisation confirmed full Unicode at installation and tested with three deliberately awkward names before going live. An import from a legacy system later produced mangled characters, which was traced to the file’s own encoding rather than the database and fixed at the import.

Recommendations

• Keep full Unicode — the default is right.
• Never change it casually on a database with data.
• Check the connection layer, not just the database.
• Test with real, awkward names.