Configure a workspace

01In a sentence #sec_e99b10e0

Settings are where an entity sets its governance: the time over which deadlines are calculated, the default behavior of its campaigns, its notification templates, and the two override levers that are exclusions and delegations.

02The principle: three levels, never overridden #sec_7541045c

A governance setting only makes sense if you know where it comes from. REVIEWIT therefore applies the same cascade everywhere:

Défaut produit  →  Réglage du workspace  →  Réglage de la campagne
   (le socle)        (l'entité décide)        (le cas particulier)

Three practical consequences, and these are what give value to the screen:

1. Setting nothing is a valid choice. A workspace that has not changed anything operates on the product foundation, and the screen explicitly states this — a gray badge « Default configuration ». As soon as a local setting exists, the badge turns purple, « Workspace configuration ». You can see at a glance whether the entity has exercised its autonomy.

2. The deviation is signaled, value by value. Each setting that differs from the foundation has a purple dot. An administrator taking over a workspace after someone else immediately sees what has been customized, without having to compare anything.

3. Rolling back is clean. Restoring the default configuration removes local settings — it does not copy them. The workspace actually returns to the foundation and will now follow its evolutions.

The third level — the campaign — is not on this screen: what is set here constitutes the default behavior proposed by the campaign assistant, which remains adjustable campaign by campaign.

03The page #sec_205b4606

Six entries, in two families.

The separation is not cosmetic. Organization groups what describes the entity itself — its time, its representation relationships — and which holds regardless of any campaign. Campaigns & reviews groups what shapes the exercise of control.

# Organization

04Working time #sec_203bf130

Business days, hours, holidays, and time zone of the workspace.

This is the most discreet and structuring setting: all product deadlines are calculated on this calendar, not on calendar days. A five-business-day contestation period opened on a Thursday does not end on the following Tuesday if Monday is a holiday in the entity's country.

Four settings:

The time zone. It determines what « today » means for this workspace. The screen displays the current local time, to remove any ambiguity at the time of setting.

Business days. The workweek, day by day. The default is Monday–Friday, but nothing imposes it: entities whose business week differs — common in the Middle East — declare it here, and the entire product follows.

Hours. Start and end of the day, with consistency control.

Holidays. Two modes coexist, and this is intentional:

• Country discovery — choose a country, the product proposes its calendar, and you import it in one go. The days obtained this way carry the Discovered badge.
• Manual entry — for anything a national calendar does not know: company closure, local bridge, conventional holiday.

The distinction is preserved in the list: you always know whether a date comes from a reference or a local decision. A permanent summary recalls the effect of the setting — number of working days, hours per day, hours per week.

Why this setting is at the workspace level

Because this is exactly what delegated governance must be able to decide alone. Headquarters has no reason to impose the French calendar on an Indian subsidiary, and a deadline calculated on the wrong calendar produces fictitious delays, unjustified follow-ups, and ultimately distrust of the system.

05Delegation #sec_19455fd5

Authorize trusted people to act on behalf of other members.

The full screen is the subject of a dedicated sheet: [Delegation](REVIEWIT_Feature_Delegation_v1.0.md).

What to remember here: a delegation is a motivated cycle, limited to twelve months and never deleted — it is revoked. It is one of the two levers by which an entity could arrange itself with the control entrusted to it, hence the level of requirement.

This entry appears only if the subscription has granted the capability to the workspace.

# Campaigns & reviews

06Recertification rules #sec_9254e515

Default behavior of campaigns and access reviews — adjustable campaign by campaign.

This is the heart of the screen: thirteen settings that determine what a reviewer can do, and what will be required of them. They are grouped into five families.

Decisions & notifications

The last one deserves a word. Consultation is the escape route that avoids the most complacent certifications: it allows saying « I don't know » without delegating, without escalating, and without ticking yes by default. The reviewer retains the decision and accountability, they only obtain the missing information.

As for required comments, they are set separately for approval and revocation, because the two actions do not have the same cost. Many organizations only require justification for revocation — the decision that will produce a complaint.

Contestation

The duration setting appears only if contestation is active — a nested panel unfolds under the parent rule. The product never asks to set a parameter that will not be used.

An automatic implication applies here, and its processing illustrates a product design rule.

When the contestation period is active, the required comment for revocation becomes forced: the contestant must be able to read the reason for the decision they are contesting, otherwise the contestation has no purpose. The interface therefore shows it as activated and locked, with a note explaining why.

But — and this is the point — the value you had chosen is not overridden. If you later deactivate contestation, your original setting reappears as is. The product displays a constraint; it does not rewrite your intention for you.

Exceptions

Same nested panel logic. An exception without a duration would be a permanent override — the product does not propose this case.

Delegation

This setting illustrates a second design rule. In the database, it is stored negatively — in a form such as « disable transfer ». The interface displays the capability, never the internal flag: the switch is titled « Delegation transfer », and activated means authorized.

This is more than a convenience. A negative setting produces double negatives — « disable transfer: no » — whose interpretation is a classic source of error in security configuration. The storage remains inverted to break nothing existing; the display, however, is aligned with how a human thinks.

On the substance, allowing transfer means allowing delegation chains — A delegates to B who delegates to C. This is legitimate in some organizations, and it is reported as an audit finding in the Delegation screen.

Bulk actions

Four distinct switches, and not just one, because these actions do not have the same scope. Many organizations allow bulk revocation and reassignment while prohibiting bulk approval — because it is precisely through it that a campaign empties of its substance: eighty lines checked in one click produce a perfect rate and zero examination.

This is the most revealing setting of an organization's real requirement, and it deserves to be decided consciously.

07Email Catalog #sec_18c05906

Email templates used by your campaigns: follow-ups, notifications, reminders.

Notifications are the only part of the product that reviewers see before opening the application. Their tone, clarity, and language determine the response rate—therefore, indirectly, the quality of the campaign.

The catalog applies a three-level cascade:

Modèle local du workspace  →  Modèle global  →  Modèle embarqué

The product uses the first one found. A workspace that has not customized anything receives the global templates; a workspace that has redefined a specific notification redefines only that one.

A template is identified by a trigger and a language: each notifiable event has its version in each served language. You will find its name, category, language, status, and modification date, with preview, import, and export.

Templates provided by the product are marked as such: they cannot be deleted, but they can be duplicated—the copy becomes a local template that the entity makes its own. This is the safest way to customize: start from what works, and the core remains intact underneath.

This entry appears only if the subscription has granted the local catalog capability.

08Exclusions (Sanctuary) #sec_968bf03d

Exclude users, resources, or workloads from the scope of reviews.

Dedicated sheet: [Sanctuary](REVIEWIT_Feature_Sanctuary_v1.0.md).

To remember here: an exclusion is a motivated, dated cycle, with a mandatory review deadline, and never deleted—it is lifted. It is the second override lever for an entity, and the first place an auditor looks: what escapes control, and why.

A graduated safeguard applies to volume—information at 5% of the excluded scope, alert at 10%, ceiling at the subscription quota.

This entry appears only if the subscription has granted the capability.

09Deletion Requests #sec_3a0dc622

Consolidated view of resource deletion requests issued in campaigns.

During a review, an owner may find that a resource no longer has a reason to exist. They do not delete it—they request it, and this request comes up here.

The screen consolidates, for the entire workspace: the resource concerned, the originating campaign, the requester, the reason, the date, the status, the processing date, and the storage volume concerned—pending and already freed.

Two design points:

The request is not the deletion. The reviewer signals, the workspace arbitrates, execution falls to another system with its own tracking. No data is destroyed by a review decision.

Cancellation is motivated. Refusing a request requires justification, like any governance decision in the product.

The storage aggregate is not decorative: it transforms a governance hygiene into a measurable benefit and feeds the workspace's carbon score.

10What is Not Here #sec_5a9dbca2

Certain settings do not belong to the workspace, and their absence from this screen is intentional. They fall under the subscription, which sets the envelope:

An ungranted capability does not appear in the settings: no card, no menu, no grayed-out button. A granted but capped capability remains visible and locked, with the mention of who governs it—a local administrator must be able to see that the function exists and know who to ask.

See the [Workspace Center chapter](REVIEWIT_Chapter_WorkspaceCenter_v1.0.md).

11Roles and Traceability #sec_774db7be

The screen is reserved for the workspace Manager. The Auditor accesses the two governance screens—exclusions and delegations—in read-only mode because these are the ones that document overrides; they do not perform any action and see it reminded by a permanent banner.

Settings that engage the credibility of the system are traced: every exclusion and every delegation carry their author, reason, justification, and dates, and are never erased.

12To Remember #sec_9f2a2a96

Workspace settings are the concrete expression of delegated governance: this is where an entity exercises the autonomy it has been entrusted with, and here is where one can verify how it has exercised it.

Three ideas run through them. The cascade always makes it readable where a setting comes from and allows one to renounce it cleanly. Constraints are displayed, never applied silently to your data. And the two levers by which one could loosen control—exclude from scope, have someone else decide—are the two that require the most justification.

A recertification system is not judged by what it allows, but by what it obliges one to write when deviating from it.