Practical workflows

Scenario A: a new internal project

Goal: the team develops an internal “Claims Portal” system.

1. Create a project:

``text Code: CLAIMS Name: Claims Portal Visibility: Private ``

2. Create repositories:

• server;
• windows-client;
• documentation.

1. Create group CLAIMS-DEVELOPERS.
2. Add developers to the group.
3. Grant Developer on project CLAIMS.
4. Grant the technical writer Maintainer only on documentation.
5. Each user creates a workspace with the Desktop Client.

Scenario B: partial workspace for a DBA

The DBA should work only on SQL files.

1. Grant path permission for /database/sql.
2. Select /database/sql in the repository browser.
3. Open checkout and choose partial mode.
4. Create a workspace such as:

``text C:\Work\Claims-SQL ``

5. The DBA sees and changes only the permitted scope.

Scenario C: running behind Digi Wall

DigiVC internal listener: HTTP 0.0.0.0:8000
Digi Wall public endpoint: https://digivc.company.example
DigiVC public URL: https://digivc.company.example

Digi Wall terminates TLS and forwards to the internal HTTP listener. DigiVC setup must not require a local TLS key in this mode.

Scenario D: remote PostgreSQL without SSL

Host: 10.10.0.40
Port: 5432
SSL mode: disable

Use this only on a controlled protected network. If PostgreSQL later receives a valid certificate, move to verify-full.

Scenario E: migration from GitLab

1. Create a target project.
2. Select GitLab as source.
3. Enter URL and token.
4. Keep TLS verification enabled.
5. Select full history.
6. After success, verify revision mapping and perform a test checkout.

Scenario F: a safe change

1. Open the workspace.
2. Update.
3. Make the change.
4. Status.
5. Diff.
6. Run validation checks.
7. Commit with a clear message.
8. Verify the new revision in WEB/Admin.