Considerations: Naming

(on-premises only) After a site is created, changing its site ID is time-consuming and requires a complete stoppage of work in all databases that communicate with, or replicate to, that site.

The site ID should remain the same throughout your test, pilot, and production phases, if possible.

Avoid generic site names (for example, "Site1") that do not differentiate your sites. Use names that describe the location, the hierarchy, or what the site is used for.

(cloud only) Configurations for your sites are named based on Infor standards.

Avoid using these special characters in configuration names and site IDs or site names:

\ (back slash)
/ (forward slash)
: (colon)
* (asterisk)
? (question mark)
" (double quote)
’ (single quote)
< (left arrow)
> (right arrow)
| (vertical bar)
(embedded space)

(on-premises only) The site ID and the site name should relate to each other, if possible. The site name can be much longer than the ID. For example, if your Site ID is ARIZ, your site name could be Arizona.

You might want to include the type (site or entity) information in the site name. If you have multiple sites in one application database, the database name should be more generic but still descriptive.

(on-premises only) See also the information on configuration names in Configuration names.

(on-premises only) In web server names, avoid using special characters other than '-' or '.' A Microsoft security feature does not preserve session state when web server names in URLs contain other special characters. If your web server must use other special characters, use the IP address in URLs pointing to the server.

For site groups, use names that define their function (for example, FINANCE) or their location (for example, PACIFIC), depending on the logical grouping.

Do you want to use prefixes to distinguish site-specific customers, vendors, jobs, transfer orders, purchase orders, and so on?