🧩 Lab overview — business scenario

Your organization wants a central Risk Library to capture risk items and a Control Library to capture controls. Risks
must link to controls, access must be controlled by teams (L1/L2, Risk Review, Security, Business Unit Managers), and
record permissions must be a mix of manual, automatic, and inherited depending on conditions. Certain
fields/sections should appear only for specific conditions and some fields must be required/read-only depending on
state.

Prereqs (do this first)

1. You are a System or Application Admin in Archer.

2. Basic apps (Department or Business Unit) exist with a field that contains the manager (used for inherited RP).
If not, create a simple Department app with Department Name and Dept Manager (User) first.

3. Decide test users (create 6 test users) — you’ll assign them to groups below.

Part 1 — Create the two applications

Step 1 — Create Risk Library

1. Admin → Application Builder → Create Application.

2. Name: Risk Library. Description: “Central register of organizational risks.”

3. Create sections: Risk Details, Assessment, Remediation, Documents.

4. Save & Publish.

Step 2 — Create Control Library

1. Admin → Application Builder → Create Application.

2. Name: Control Library. Description: “Catalog of controls, owners and assessments.”

3. Create sections: Control Details, Implementation, Testing, Attachments.

4. Save & Publish.

Part 2 — Global Value Lists (GVLs) & Value Lists

Create reusable lists first.

Step 3 — Create GVLs

Admin → Application Builder → Global Value Lists → Add:

 GVL_RiskCategories: Operational, Strategic, Compliance, Financial, Reputational

 GVL_Impact: Catastrophic, Major, Moderate, Minor

 GVL_Likelihood: Very Likely, Likely, Possible, Unlikely

 GVL_ControlType: Preventive, Detective, Corrective, Compensating

 GVL_Departments: Finance, HR, IT, Legal, Operations (if you don’t have a Department app)

Use these GVLs on fields to ensure consistency and easier maintenance.

Part 3 — Create Groups, Access Roles, Users

Create groups and roles BEFORE record permissions (best practice).

Step 4 — Create Groups

Access Control → Groups → Create the groups:

 Risk L1 Analysts

 Risk L2 Analysts

 Risk Review Team

 Risk Security Team

 Control Owners

 Business Unit Managers

 HOD (Head of Risk or similar)

Add your test users to these groups.

Step 5 — Create Access Roles

Access Control → Access Roles → Create:

 Role_RiskOwner → Grant Create, Read, Update on Risk Library.

 Role_RiskReviewer → Read/Update on Risk Library, Read on Control Library.

 Role_ControlOwner → Create/Read/Update on Control Library.

 Role_Security → Read/Update on both apps (as appropriate).

Assign roles to the appropriate groups (prefer groups over individual users).

Part 4 — Fields & Record Permissions in Risk Library

We’ll create normal fields, manual RP, automatic RP, inherited RP, and calculated fields.

Step 6 — Add core fields to Risk Library

Application Builder → Risk Library → Fields → Add:

Under Risk Details:

 Risk ID — Auto/Unique (text or auto-number)

 Risk Title — Text (short)

 Risk Category — Values List → use GVL_RiskCategories

 Department — Cross Reference → Department application (important for inherited RP)

 Risk Owner (User) — User field (optional)

Under Assessment:

 Impact — Values List → GVL_Impact

 Likelihood — Values List → GVL_Likelihood

 Risk Score — Calculated Numeric (see Step 9)

  Risk Level — Values List → High / Medium / Low (you will populate based on risk score via calc later)

Under Remediation:

 Remediation Plan — Text Area

 Mitigation Deadline — Date

 Closure Comment — Text Area

Under Documents:

 Risk Evidence — Attachments

 Related Controls — Cross Reference → Control Library

Step 7 — Create Record Permission fields (multiple types)

Add RP fields (Fields → Add):

1. RP – Risk Owner — Record Permissions (Manual)

o Purpose: manual assignment of who owns the risk. Allow groups: Risk L1 Analysts as default choices;
user picker will let setting to individual owner.

2. RP – Risk Review Team — Record Permissions (Automatic)

o Purpose: should be populated automatically when a risk becomes High or when Risk Category =
Compliance. Initially leave blank (will populate via a DDE rule).

o NOTE: Automatic RP fields are defined in field properties; DDE rules will set the value.

3. RP – Dept Manager (Inherited) — Record Permissions (Inherited)

o Purpose: inherit RP from the linked Department record’s Dept Manager RP (or Dept Manager user
field).

o When configuring: choose the cross-reference Department as the reference source and specify which
permission to inherit (e.g., Dept Manager/Dept RP). This means whoever has permission on the
Department record gets appropriate access to this risk.

4. RP – Security Team — Record Permissions (Automatic)

o Purpose: auto-grant Security Team update access when Risk Category = Compliance OR Impact =
Catastrophic.

Set appropriate default visibility on forms.

Part 5 — Calculated fields (simple examples)

Step 8 — Add calculated fields

Add these calculated fields to Risk Library → Fields:

A. Calc – Risk Score (Numeric, Calculated)

 Formula (pseudo / use Insert Field + functions): convert Impact and Likelihood to numeric weights and
multiply. Example logic:

 IF([Impact] = "Catastrophic", 5,

 IF([Impact] = "Major", 4, IF([Impact]="Moderate",3,1))

 )*
  IF([Likelihood] = "Very Likely",5, IF([Likelihood]="Likely",4, IF([Likelihood]="Possible",3,1)))

Use the calculation editor and Insert Field; break into helper calcs if needed.

B. Calc – Risk Level (Values/Text, Calculated)

 Formula:

 IF([Calc – Risk Score] >= 16, "High",

 IF([Calc – Risk Score] >= 8, "Medium", "Low"))

Save both and set recalculation to run when referenced fields change.

Part 6 — DDE rules & ACLs in Risk Library

We’ll use Designer → Actions to create rules & ACL actions that set automatic RPs, show/hide sections and make
fields required/read-only.

Step 9 — Rule: When Risk Level = High

1. Application Builder → Risk Library → Layout → Designer → Actions.

2. Create Rule: Rule_Risk_Level_High

o Condition: Calc – Risk Level Equals High.

3. Actions linked to this rule:

o Action A (Apply Conditional Layout): Show Remediation section and set Mitigation Deadline
Required.

o Action B (Set Record Permission): Populate RP – Risk Review Team with the group Risk Review Team
(Automatic RP).

o Action C (Set Record Permission): Populate RP – Security Team with Security Team. (If you want
Security only for Compliance/High Impact, include that combined condition or separate rule.)

Name actions clearly: ACL_Show_Remediation_High, AutoRP_Set_RiskReview_High, AutoRP_Set_Security_High.

Step 10 — Rule: When Risk Category = Compliance

1. Create Rule: Rule_Risk_Category_Compliance

o Condition: Risk Category Equals Compliance.

2. Actions:

o Action A: Set RP – Security Team = Security Team (Automatic).

o Action B: Make field Risk Evidence Required using ACL (Apply Conditional Layout).

Step 11 — Rule: when Department is set (Inherited RP)

1. For inherited RP you already configured the field. Add an ACL rule if needed:

o e.g., Rule_Department_Assigned → Condition: Department is not empty.

o Action: Show a read-only summary of Dept Manager name (helpful for auditors) or set a notification
to Dept Manager. Inheritance itself does not need DDE; it's configured at field level.

Step 12 — Rule: Low/Medium level behaviour

  Create Rule_Risk_Level_Low and Rule_Risk_Level_Medium to hide Remediation or make only minimal fields
required, e.g., hide Remediation when Low.

Part 7 — Fields & RPs in Control Library

Mirror similar patterns in Control Library.

Step 13 — Add Control fields

Under Control Details:

 Control ID (auto)

 Control Title (text)

 Control Type — Values List → use GVL_ControlType

 Control Owner (User) — User field

 Implementing Team — Group/Values List (IT Ops, Business, HR) — create GVL or groups

Under Implementation:

 Control Status — Values List: Draft, Implemented, Not Effective, Retired

 Implementation Date — Date

 Control Evidence — Attachments

Under Testing:

 Last Test Date — Date

 Test Result — Values List: Effective, Partially Effective, Not Effective

Add Related Risks → Cross Reference → Risk Library

Step 14 — Add RP fields (Control Library)

1. RP – Control Owner — Manual Record Permission (default to Control Owners group)

2. RP – Implementing Team (Inherited) — Inherited Record Permission from a Business Unit cross-ref (or
Department) so business unit managers get access.

3. RP – Security Team (Auto) — Automatic RP that is set when Control Type = Technical AND Test Result = Not
Effective.

Step 15 — ACL rules for Control Library

Examples:

 Rule: Control Status = Implemented

o ACL: Show Implementation section, set Control Evidence Required; set Implementation Date to
today (Set Date action).

o Action: Set RP – Implementing Team = selected group (you might have an implementing team value
or use a manual RP assigned earlier).

 Rule: Test Result = Not Effective

o ACL: Set RP – Security Team (Auto) to Security Team and make Control Owner notified (on-demand
or subscription notification to that group).
Part 8 — Cross-reference fields (linking Risk ⇄ Control)

Step 16 — Add cross refs and enforce filter

1. In Risk Library add Related Controls → Cross Reference to Control Library.

2. In Control Library add Related Risks → Cross Reference to Risk Library.

3. Optionally add a DDE Filter: if Risk Category = Compliance, filter Related Controls to show only controls of
Control Type = Detective or a specific list.

Part 9 — ACL test scenarios and how to run them

Provide the trainee with explicit test steps.

Test 1 — High risk path & automatic RPs

1. Login as a user in Risk L1 Analysts. Create a new Risk: set Impact = Catastrophic, Likelihood = Very Likely.

2. Save → Calc – Risk Score should calculate high value and Calc – Risk Level = High.

3. Expected: Remediation section is visible; Mitigation Deadline required; RP – Risk Review Team and RP –
Security Team automatically populated (check Security Team and Risk Review Team members can access).
Also Department Manager (via inherited RP) should see record if Department set.

Test 2 — Compliance category

1. Create Risk with Risk Category = Compliance.

2. Expected: RP – Security Team auto populated; Risk Evidence field becomes required; event logs show which
DDE actions fired.

Test 3 — Control not effective

1. Create a Control, set Control Type = Technical. Set Test Result = Not Effective.

2. Expected: RP – Security Team auto populated and Control Owner notified; Control Evidence required when
status = Implemented.

Test 4 — Inherited RP validation

1. Create a Department in the Department app with Dept Manager user = Alice.

2. Create a Risk and select that Department.

3. Expected: Alice (Dept Manager) has inherited access as configured.

How to verify:

 Use event analyzer for DDE troubleshooting (which rules/actions fired).

 Use “Who can see this record” utility or impersonate users to verify RPs.

 Attempt to edit as a non-permitted user (should be denied).

Part 10 — Deliverables for the trainee to hand back

Ask trainee to produce:

1. A Configuration Log: list of fields added, RP fields and their types, GVLs created (values listed).
 2. A DDE Matrix: rule name, condition, actions created (ACLs, RP writes, set date) and expected behavior.

3. Screenshots (or short video) of: RP fields populated, Remediation section shown, inherited RP working,
Control Evidence required.

4. A Test Result Sheet (for tests above): test steps, expected, actual, notes.

5. Optional: short one-page diagram showing Risk ⇄ Control relationships and RP flow.

Best practices & tips (short)

 Name rules & actions clearly (Rule_Risk_High → ACL_Show_Remediation).

 Use GVLs for lists used by multiple apps (helps reporting).

 Order Values Lists logically (prefix 01, 02 if lifecycle matters).

 Avoid hidden required fields — set required via ACL only when visible.

 Document inherited RP behavior (it can be opaque if not recorded).

 Use Event Analyzer to debug DDEs.

 Test with impersonation / multiple users each time you change an RP rule.

 Keep automatic RP logic deterministic — don’t create conflicting rules that assign different groups
simultaneously unless that’s intended.

Quick reference: useful names to use in the lab

 Rules: Rule_Risk_Level_High, Rule_Risk_Category_Compliance, Rule_Control_Implemented,

Rule_Control_NotEffective

 ACL actions: ACL_Show_Remediation_High, ACL_Require_Evidence_ControlImplemented

 AutoRP actions: AutoRP_Set_RiskReview, AutoRP_Set_Security

 Manual RPs: RP – Risk Owner, RP – Control Owner

 Inherited RPs: RP – Dept Manager (Inherited), RP – BusinessUnitManager (Inherited)