Tenant administrator learning path

Use this route if you maintain Finsaku configuration and user access for a tenant. It moves from dependency mapping through products and workflows to access verification.

Plan: About two hours of reading and practice.
Start with: Administration permissions, an approved change, representative test data, and a controlled test context.
Finish when: You can trace a configuration dependency, test its user effect, and verify an access change with positive and negative cases.

Route

1
Set up the tenant baseline
Confirm organisation identity, currency, time zone, language, lending capability, appearance, and initial administrator access.
Check: Reopen General Settings and verify the saved baseline from the intended tenant.
2
Set up a lending product
Create the catalogue path and product, select its calculator, and review its active definition.
Check: Start a test application and confirm the intended product, fields, and calculation appear.
3
Configure collected data
Create reusable fields and lookups, attach them to a New product version, and activate the version through the approved change process.
Check: Confirm that a new application uses the Active definition and earlier work retains its original definition.
4
Configure repeated and nested objects
Set repetition limits and reuse a nested Object Library definition without duplicating its fields.
Check: Confirm the minimum and maximum entries, nested validation, and saved summaries in a new application.
5
Set up integration partners
Configure and enable the Docugenerate, email, and SMS providers required by customer communications.
Check: Reopen each integration and confirm its selected provider and enabled state.
6
Set up documents and communications
Add the agreement, approval email, and approval SMS templates, then resolve their fields against an application.
Check: Generate the document and account for each email or SMS request in Finsaku and the provider.
7
Add event-driven triggers
Run the agreement, approval email, and approval SMS from one matching application event.
Check: Account for all three outcomes in Execution History.
8
Maintain data and workflow dependencies
Continue through objects, lookups, saved queries, decisions, event actions, and labels as required by the change.
Check: Test a matching case and a non-matching, missing-data, or failed case.
9
Configure access for a new user
Translate an approved access request into active group membership, affiliation where applicable, and a unique user account.
Check: Prove one intended operation and one neighbouring operation that must remain unavailable.
10
Review tenant-wide settings and integrations
Check languages, currencies, time zone, product capabilities, appearance, and provider dependencies affected by the change.
Check: Record the effective date, owner, tested user, and observable result of the change.
11
Review the audit trail
Use record History, change details, and recent activity to trace a supported operation to its actor, time, and affected record.
Check: Confirm that the intended administrator can inspect the change and a neighbouring role without the history permission cannot.

Role boundary

Saving a configuration proves only that Finsaku accepted the form. Verify the resulting Workspace task and, for an external service, the provider-side outcome.

Keep lending, payment deletion, export, integration editing, user administration, and impersonation permissions separate where the organisation requires independent control.