Settings course 01 — Workroom identity defaults and configuration scope

Settings governs shared identity, admission, permissions and services. Begin by confirming the workroom and the scope of the proposed change. A personal preference, workroom default and module policy are different controls, even when they appear to concern the same currency or time.

In this chapter

• Navigate the shared settings
• Read Info field by field
• Separate personal preferences and module policy
• Prepare controlled changes and starting records

Navigate the shared settings

Open the gear beside the workroom selector for Workroom Settings. Under COMPANY SETUP, Info, Domain & DNS, Business Email and Billing concern identity and services. Under ADMINISTRATION, Membership, Roles & Access and Teams & Modules concern people and access. Developers and Audit Log sit under SECURITY. Partners is a separate destination; its deeper configuration is not established in the supplied source.

The workroom selector identifies where you act; your signed-in account identifies who acts. Similar workroom names are not interchangeable. Before changing anything, compare the selected workroom with Info → Workspace Identity → Workroom name. If the page is still loading, wait for a settled view instead of treating blank fields as the saved configuration.

Read Info field by field

Workroom name is shared identity, not a task title. Regional Defaults → Default currency names a monetary unit; it is not an exchange rate. Default timezone is a shared regional default. Privacy describes the selected workroom policy. The source's Private helper restricts admission to invited members, but that does not substitute for testing access to a particular shared record.

The Info helper says individual modules can override defaults in their own settings. Check the relevant module before interpreting a discrepancy; do not assume a universal precedence or historical rewrite rule for every field. Save Changes is a shared configuration action. Opening the page and reading a value does not save anything, and changing a default must not be used to make an unrelated training example appear consistent.

The source teaching workroom uses USD, Africa/Lagos and Private. Those are example values, not recommendations for another business. Record the actual intended value, business reason and affected workflows before an approved change.

Separate personal preferences and module policy

The retained account route is Quick Actions → Account → My Profile → Preferences. A travelling user's timezone preference belongs to that account context; it does not automatically justify changing the whole workroom. Avoid copying personal contact details into a configuration note.

Module settings express specialist policy. For example, Produce has issue method, reservation, backflush and final-quality controls; Assets has currency, capitalisation and approval policy. A shared timezone or currency setting does not turn off those workflow gates. Consult that module's owner and course before proposing an operational policy change.

For a fictional workroom whose shared timezone is Africa/Lagos and whose user prefers Europe/London, keep both facts. A task due on November 9 as a calendar date should not acquire an invented hour or move to November 8 through a guessed conversion. For a timestamp, identify the precise field and displayed timezone or offset first. If a worksheet says NGN while Info says USD, resolve the worksheet's source and module basis; do not relabel amounts without an authorised conversion.

Prepare controlled changes and starting records

A useful change note identifies setting location, current value, desired value, reason, affected users/workflows, decision owner and acceptance check. Name what must stay unchanged. After an approved save, reopen the exact setting and verify retained values. Check a permitted new record and an existing record separately where relevant; do not promise that defaults rewrite historical data.

Starting data also needs exact identity and ownership. Keep a source key separate from the application's returned identifier. A task title should describe workflow, action and object; changing owner, due date and status belong in their proper fields rather than a title such as urgent-final-today. Exclude credentials and private contact information from naming conventions.

Deduplicate by source identity and purpose, not simply identical titles. If two proposals refer to the same checklist review, reconcile them before entry. If a required owner or date is missing, hold that row instead of choosing the first selector value. Settings is not evidence that every module offers bulk import; use the actual module's supported entry form.

If a save result is uncertain, inspect the existing object before retrying. A duplicate configuration or starting record creates more ambiguity. Recovery should use the recorded prior state and the responsible owner's decision, not a remembered value applied blindly.