Scout Administration

Use this guide when enabling Scout for a tenant or onboarding a customer team.

What Must Be Enabled

Scout is an optional DFS Pro capability. A user can access it only when:

• DFS Pro is active for the tenant;
• Scout is active for the tenant;
• the user has permission for the requested action.

Enable DFS Pro before Scout. Disabling DFS Pro also makes Scout unavailable.

Recommended Roles

Customer role	Access needed	Typical users
Viewer	Read Missions, gaps, matches, and readiness evidence	Operations leader, auditor
Data operator	Viewer access plus create and investigate	Data engineer, integration engineer
Reviewer	Viewer access plus binding decisions	Data steward, domain engineer
Approver / deployment owner	Approve validation, review the DFS diff, and apply bindings	Data owner, application owner, platform operations
Tenant administrator	Enable modules and manage role membership	Customer system administrator

Use the minimum role required. Keep semantic review and approval responsibilities explicit, even when the same person performs several tasks in a small team.

Enablement Steps

1. Confirm the tenant is licensed for DFS Pro and Scout.
2. Enable DFS Pro in tenant module management.
3. Enable Scout.
4. Assign users to the customer roles above.
5. Sign in as a viewer and confirm the Scout menu and Mission list are visible.
6. Sign in as a data operator and confirm a Mission can be created in an approved test scope.
7. Confirm users without access cannot open Scout directly.

Business Readiness

Before the first Mission, confirm:

• an application owner has published the data requirements;
• the customer has selected a bounded site, system, or equipment scope;
• source and asset owners are named;
• the source signals and asset definitions are governed in DFS and Digital Twin;
• time-series storage is reachable for the tenant;
• the target application is installed and owned;
• reviewers, approver/deployment owners, and escalation contacts are named;
• the team agrees how customer, demonstration, and unverified data will be labeled.

Scout can show a missing prerequisite, but it cannot replace the owner or approval for that prerequisite.

Readiness Test

Use a small non-production or approved demonstration scope to verify:

1. A viewer can read a Mission but cannot change it.
2. A data operator can create and investigate.
3. A reviewer can accept or reject a proposal.
4. An approver can approve a passing validation but cannot edit candidate meaning.
5. A deployment owner can preview and apply only the approved Mission bindings.
6. The readiness result reports missing data as unavailable, not as zero.

Do not use customer data outside its approved scope for this test.

Operating Ownership

Record the owner for each area before go-live:

Area	Owner responsibility
Tenant access	Modules, users, roles, sign-in
Source integration	Connector, source signal, credentials, availability
Asset model	Asset identity, schema, attribute meaning
Time-series service	Tenant routing, retention, availability
Application	Requirement version, installation, result
Scout	Mission workflow, gap/match decisions, validation, and readiness evidence

Disabling Scout

Before disabling, review open matches, validations awaiting approval, and active DFS bindings. Disabling the module hides and blocks Scout workflows; it does not erase review history or automatically remove data bindings used by another application. Plan downstream changes with the relevant owners.

Use Troubleshooting and Go-Live for the final handover checklist.