1. 1 Introduction
2. 1.1 Terms of Service
3. 1.2 Privacy
4. 1.3 Support
5. 2 Logging in and getting started
6. 2.1 Understanding the difference between the basic and webhook enabled apps
7. 3 Workspaces
8. 3.1 Members administration and access levels
9. 3.2 Hierarchy naming schemes
10. 3.3 Free versus paid licences
11. 3.4 Organizations within a workspace
12. 4 Organizations
13. 4.1 Repos
14. 4.1.1 Mapping an organization to a collection of repos
15. 4.1.2 Setting up ignoring and scanning repos
16. 4.1.3 Supported languages and component discovery
17. 4.1.4 Specific repo page
18. 4.2 Components
19. 4.2.1 Specific component page
20. 5 Roadmap

Hierarchy naming schemes

Hierarchy naming schemes tell the Dashboard how to describe the layers above a component.

For example, different users, teams and companies might want to think in terms such as:

• domain,
• product,
• service,
• module,
• or another set of names that better fits their structure.

Why this matters

The Silverfish IDP discovers components from repos, but each company describes structure differently. Hierarchy naming schemes lets the Dashboard use your terminology instead of forcing a single model on every team.

Workspace-level benefit

Hierarchy naming schemes are defined at workspace level so they can be reused across your organizations. This makes it easier to stay consistent.

Organization-level flexibility

Different organizations inside the same workspace can still use different schemes where needed. That gives you a shared catalog of allowed structures without removing flexibility.

Defaults

A workspace has a default hierarchy naming scheme. That default can be changed, and additional schemes can be added, edited, deleted, or restored to the shipped defaults where supported.