Skip to content

Commit cbcac11

Browse files
aleksandarkovacevic30aleksandarkovacevic30
authored
Merge pull request #959 from CluedIn-io/docs/learning-paths
adding two courses
2 parents dcf3799 + e33d42c commit cbcac11

17 files changed

Lines changed: 785 additions & 0 deletions

‎docs/120-learning-paths/000-learning-paths.md‎

Lines changed: 31 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,31 @@
1+
---
2+
layout: cluedin
3+
title: Learning paths
4+
permalink: /learning-paths
5+
nav_order: 120
6+
has_children: true
7+
tags: ["learning-paths", "training"]
8+
---
9+
## On this page
10+
{: .no_toc .text-delta }
11+
- TOC
12+
{:toc}
13+
14+
This section contains role-based learning paths for CluedIn. Each course is designed to guide a learner through the instance gradually, starting with shared orientation and then moving into role-specific workflows.
15+
16+
## Available courses
17+
18+
- [Data Steward course](/learning-paths/data-steward-course)
19+
- [Data Architect course](/learning-paths/data-architect-course)
20+
21+
## Design principles
22+
23+
These courses are written to be applied in a **dev** or **test** environment first. They assume that learners should become confident in reading the instance before they are asked to configure or clean anything at scale.
24+
25+
## How to use this section
26+
27+
1. Start with the course overview.
28+
1. Run the shared foundation module first.
29+
1. Move through the modules in order.
30+
1. Use the exercises as workshop tasks or self-guided practice.
31+
1. Use the completion checks to decide when a learner is ready for the next step.

‎docs/120-learning-paths/010-data-steward-course.md‎

Lines changed: 49 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,49 @@
1+
---
2+
layout: cluedin
3+
title: Data Steward course
4+
parent: Learning paths
5+
permalink: /learning-paths/data-steward-course
6+
nav_order: 10
7+
has_children: true
8+
tags: ["learning-paths", "data-steward", "training"]
9+
---
10+
## On this page
11+
{: .no_toc .text-delta }
12+
- TOC
13+
{:toc}
14+
15+
The Data Steward course is designed to make a learner comfortable reading quality signals, investigating suspicious records, fixing visible issues, and confirming the result inside CluedIn.
16+
17+
## Course goal
18+
19+
A learner completing this course should be able to:
20+
21+
- navigate the instance confidently;
22+
- isolate a problem population with search and filters;
23+
- review source-level validation issues;
24+
- review duplicate candidates and make stewardship decisions;
25+
- verify the effect of a fix in the product.
26+
27+
## Recommended audience
28+
29+
Use this course for data stewards, business data owners, operational data quality analysts, or any user who needs to investigate and resolve visible data issues inside the product.
30+
31+
## Prerequisites
32+
33+
- Access to a **dev** or **test** environment.
34+
- A data set with mapped records.
35+
- Permission to review records, saved searches, validations, and deduplication outputs.
36+
37+
## Suggested sequence
38+
39+
1. [Course overview and setup](/learning-paths/data-steward-course/course-overview-and-setup)
40+
1. [Shared foundation and safe environment](/learning-paths/data-steward-course/shared-foundation-and-safe-environment)
41+
1. [Orientation in the instance](/learning-paths/data-steward-course/orientation-in-the-instance)
42+
1. [Investigate with search and filters](/learning-paths/data-steward-course/investigate-with-search-and-filters)
43+
1. [Review source-level validations](/learning-paths/data-steward-course/review-source-level-validations)
44+
1. [Review and resolve duplicates](/learning-paths/data-steward-course/review-and-resolve-duplicates)
45+
1. [Run the steward operating loop](/learning-paths/data-steward-course/run-the-steward-operating-loop)
46+
47+
## Completion check
48+
49+
A learner is ready to operate as a Data Steward when they can independently identify a recurring issue, narrow the affected records, decide how to handle them, and verify the outcome in the instance.

‎docs/120-learning-paths/020-data-architect-course.md‎

Lines changed: 49 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,49 @@
1+
---
2+
layout: cluedin
3+
title: Data Architect course
4+
parent: Learning paths
5+
permalink: /learning-paths/data-architect-course
6+
nav_order: 20
7+
has_children: true
8+
tags: ["learning-paths", "data-architect", "training"]
9+
---
10+
## On this page
11+
{: .no_toc .text-delta }
12+
- TOC
13+
{:toc}
14+
15+
The Data Architect course is designed to make a learner comfortable shaping how data enters, maps, validates, and is governed in CluedIn.
16+
17+
## Course goal
18+
19+
A learner completing this course should be able to:
20+
21+
- explain how dev, test, and production should be used;
22+
- review source mapping and identifier design;
23+
- use vocabulary and Data Catalog concepts as the shared data language;
24+
- connect repeated steward pain points to architectural changes;
25+
- prepare promotable configuration in test before production.
26+
27+
## Recommended audience
28+
29+
Use this course for data architects, solution architects, platform owners, implementation consultants, and technical product owners who are responsible for data model and governance decisions.
30+
31+
## Prerequisites
32+
33+
- Access to a **dev** or **test** environment.
34+
- At least one mapped data set available for review.
35+
- Permission to review mappings, vocabulary, validations, and management surfaces.
36+
37+
## Suggested sequence
38+
39+
1. [Course overview and setup](/learning-paths/data-architect-course/course-overview-and-setup)
40+
1. [Shared foundation and safe environment](/learning-paths/data-architect-course/shared-foundation-and-safe-environment)
41+
1. [Environment discipline](/learning-paths/data-architect-course/environment-discipline)
42+
1. [Review mapping and identifiers](/learning-paths/data-architect-course/review-mapping-and-identifiers)
43+
1. [Vocabulary and Data Catalog](/learning-paths/data-architect-course/vocabulary-and-data-catalog)
44+
1. [Rules, streams, glossary, and enrichers](/learning-paths/data-architect-course/rules-streams-glossary-and-enrichers)
45+
1. [Promote from dev to test to production](/learning-paths/data-architect-course/promote-from-dev-to-test-to-production)
46+
47+
## Completion check
48+
49+
A learner is ready to operate as a Data Architect when they can explain how a source should map, which identifiers are safe, what vocabulary language should be used, and how repeated stewardship issues should be prevented by design.

‎docs/120-learning-paths/data-architect-course/010-course-overview-and-setup.md‎

Lines changed: 47 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,47 @@
1+
---
2+
layout: cluedin
3+
title: Course overview and setup
4+
parent: Data Architect course
5+
grand_parent: Learning paths
6+
permalink: /learning-paths/data-architect-course/course-overview-and-setup
7+
nav_order: 10
8+
tags: ["learning-paths", "data-architect", "training"]
9+
---
10+
## On this page
11+
{: .no_toc .text-delta }
12+
- TOC
13+
{:toc}
14+
15+
This module introduces the architect role focus and explains how this course differs from the steward path.
16+
17+
## Learning objective
18+
19+
Learn the architect role focus: model the data, shape the source onboarding path, define the shared language, and turn repeated issues into design decisions.
20+
21+
## What this role owns
22+
23+
Based on the documentation, the Data Architect role is naturally aligned to design and governance work such as:
24+
25+
- mapping review;
26+
- identifier design;
27+
- vocabulary and Data Catalog structure;
28+
- validation design context;
29+
- rules, streams, glossary, enrichers, and promotion discipline.
30+
31+
![Built-in AI agents]({{ "/assets/images/management/ai-agents/built-in-ai-agents/builtin_agents_sp.png" | relative_url }})
32+
33+
## Before you begin
34+
35+
- Use a **dev** or **test** environment first.
36+
- Make sure learners understand that architecture decisions should not be learned for the first time in production.
37+
- Have at least one mapped source available for review.
38+
39+
## Success criteria
40+
41+
The learner can describe the architect workflow in one sentence: **understand the environment → review mapping → shape the model → govern the behavior → promote safely**.
42+
43+
## Related documentation
44+
45+
- [Review mapping](/integration/review-mapping)
46+
- [Vocabulary](/management/data-catalog/vocabulary)
47+
- [Validations](/integration/additional-operations-on-records/validations)

‎docs/120-learning-paths/data-architect-course/020-shared-foundation-and-safe-environment.md‎

Lines changed: 42 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,42 @@
1+
---
2+
layout: cluedin
3+
title: Shared foundation and safe environment
4+
parent: Data Architect course
5+
grand_parent: Learning paths
6+
permalink: /learning-paths/data-architect-course/shared-foundation-and-safe-environment
7+
nav_order: 20
8+
tags: ["learning-paths", "data-architect", "training"]
9+
---
10+
## On this page
11+
{: .no_toc .text-delta }
12+
- TOC
13+
{:toc}
14+
15+
Before an architect starts changing mapping or governance surfaces, they should share the same object model and environment discipline as everyone else.
16+
17+
## Learning objective
18+
19+
Build shared fluency in the instance before touching architecture surfaces.
20+
21+
## Key ideas
22+
23+
1. **Start safely** — use dev or test for learning and experimentation.
24+
1. **Use a staged mental model** — ingest, clean, and explore data progressively.
25+
1. **Understand the common object types** — source records, golden records, vocabulary, identifiers, and relationships.
26+
1. **Treat visible data pain as design input** — architecture should reduce recurring downstream clean-up.
27+
28+
## Practical activities
29+
30+
- Open one business domain and explain how records appear to end users.
31+
- Compare one source record journey to one golden record journey.
32+
- Explain where an architect would look for clues that mapping or model choices are weak.
33+
34+
## Expected outcome
35+
36+
The learner knows why architecture work starts from understanding the existing instance, not from writing rules in isolation.
37+
38+
## Related documentation
39+
40+
- [Search](/key-terms-and-features/search)
41+
- [Filters](/key-terms-and-features/filters)
42+
- [Vocabulary](/management/data-catalog/vocabulary)

‎docs/120-learning-paths/data-architect-course/030-environment-discipline.md‎

Lines changed: 36 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,36 @@
1+
---
2+
layout: cluedin
3+
title: Environment discipline
4+
parent: Data Architect course
5+
grand_parent: Learning paths
6+
permalink: /learning-paths/data-architect-course/environment-discipline
7+
nav_order: 30
8+
tags: ["learning-paths", "data-architect", "training"]
9+
---
10+
## On this page
11+
{: .no_toc .text-delta }
12+
- TOC
13+
{:toc}
14+
15+
This module focuses on where architecture work should happen and how changes should mature before production.
16+
17+
## Learning objective
18+
19+
Use dev for experimentation, use test for preparation and review, and treat production as the place for proven configuration.
20+
21+
## What to learn
22+
23+
- why dev is a sandbox;
24+
- why test is the preparation surface for promotable configuration;
25+
- why production should not be the first learning surface;
26+
- how to classify a change as experiment, candidate configuration, or production-ready.
27+
28+
## Exercises
29+
30+
1. List three changes that belong in dev first.
31+
1. List three changes that should be reviewed in test before production.
32+
1. Explain one scenario that should never be learned first in production.
33+
34+
## Completion signal
35+
36+
The learner stops treating promotion as a copy step and starts treating it as a governance decision.

‎docs/120-learning-paths/data-architect-course/040-review-mapping-and-identifiers.md‎

Lines changed: 48 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,48 @@
1+
---
2+
layout: cluedin
3+
title: Review mapping and identifiers
4+
parent: Data Architect course
5+
grand_parent: Learning paths
6+
permalink: /learning-paths/data-architect-course/review-mapping-and-identifiers
7+
nav_order: 40
8+
tags: ["learning-paths", "data-architect", "training"]
9+
---
10+
## On this page
11+
{: .no_toc .text-delta }
12+
- TOC
13+
{:toc}
14+
15+
This module teaches an architect how to inspect and challenge source onboarding decisions.
16+
17+
## Learning objective
18+
19+
Review a mapped source and judge whether the entity, identifiers, and relationships will produce good downstream behavior.
20+
21+
## What to learn
22+
23+
- how columns map to vocabulary keys;
24+
- what a primary identifier does;
25+
- when additional identifiers help;
26+
- how relationships should be represented.
27+
28+
![Review mapping]({{ "/assets/images/integration/data-sources/review-mapping-1.gif" | relative_url }})
29+
30+
![Primary identifier options]({{ "/assets/images/integration/data-sources/review-mapping-2.png" | relative_url }})
31+
32+
![Additional identifiers]({{ "/assets/images/integration/data-sources/review-mapping-5.png" | relative_url }})
33+
34+
## Exercises
35+
36+
1. Open an existing mapped source and review the **Map columns to vocabulary key** tab.
37+
1. Inspect the selected primary identifier and explain why it is or is not strong enough.
38+
1. Identify one possible additional identifier.
39+
1. Propose one relationship the source should create.
40+
41+
## Architect judgment to reinforce
42+
43+
Weak identifier design creates avoidable stewardship pain later. Strong identifier design gives CluedIn cleaner pre-merged records and better downstream deduplication behavior.
44+
45+
## Related documentation
46+
47+
- [Review mapping](/integration/review-mapping)
48+
- [Add relationships between records](/getting-started/relations)

‎docs/120-learning-paths/data-architect-course/050-vocabulary-and-data-catalog.md‎

Lines changed: 47 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,47 @@
1+
---
2+
layout: cluedin
3+
title: Vocabulary and Data Catalog
4+
parent: Data Architect course
5+
grand_parent: Learning paths
6+
permalink: /learning-paths/data-architect-course/vocabulary-and-data-catalog
7+
nav_order: 50
8+
tags: ["learning-paths", "data-architect", "training"]
9+
---
10+
## On this page
11+
{: .no_toc .text-delta }
12+
- TOC
13+
{:toc}
14+
15+
This module teaches an architect how to use vocabulary as the shared language for mapped and governed data.
16+
17+
## Learning objective
18+
19+
Understand vocabulary as the data language that mapping, search, filtering, stewardship, and governance all depend on.
20+
21+
## What to learn
22+
23+
- the purpose of vocabulary and vocabulary keys;
24+
- data-first vs model-first creation approaches;
25+
- how vocabulary usage reveals where a model is already embedded in the platform;
26+
- why missing or ambiguous keys create architectural friction later.
27+
28+
![Vocabulary usage]({{ "/assets/images/management/data-catalog/vocabulary-usage.gif" | relative_url }})
29+
30+
![Create vocabulary]({{ "/assets/images/management/data-catalog/create-vocabulary.gif" | relative_url }})
31+
32+
![Vocabulary keys]({{ "/assets/images/management/data-catalog/vocabulary-keys.gif" | relative_url }})
33+
34+
## Exercises
35+
36+
1. Open one existing vocabulary and inspect its usage.
37+
1. Identify one ambiguous or missing key.
38+
1. Draft how one new source should map into the current vocabulary model.
39+
1. Decide whether the scenario is better served by data-first or model-first vocabulary creation.
40+
41+
## Architect judgment to reinforce
42+
43+
If the shared language is weak, everything downstream becomes harder: mapping, search, filters, validations, and stewardship decisions.
44+
45+
## Related documentation
46+
47+
- [Vocabulary](/management/data-catalog/vocabulary)

0 commit comments

Comments
 (0)