Do you know that it’s possible to create UML diagrams in SharePoint and edit them not leaving your tenant? Yes, let’s see how it works and which types of diagrams you can edit.
What Are Your SharePoint Diagrams Likely to Be Dependent On?
Most SharePoint diagrams have a hidden dependency: the original source file. Employees see the finished image. The editable version may be in another tool, another folder or with the person who created it. When a process or system changes, updating the diagram turns into detective work. If nobody finds the source, the old visual stays and continues to look official.
Technical teams using text-based diagrams in Confluence already know a better workflow: keep the diagram source with the documentation, update it on the page and publish both together.
UML for SharePoint brings that possibility to modern SharePoint pages.
Keep diagrams editable after moving from Confluence
A Confluence-to-SharePoint migration should not force teams to turn maintainable diagrams into permanent screenshots. Teams using PlantUML or Mermaid in Confluence are accustomed to keeping the diagram code inside the documentation. When something changes, they update the source and publish the revised page.
With UML for SharePoint, teams can continue working in a similar way:
- Edit the SharePoint page.
- Add the UML for SharePoint web part.
- Enter or update the diagram source.
- Select the required diagram type and presentation settings.
- Publish the page with the rendered diagram.
- Return to the same source when the diagram changes.
The interface is different from Confluence, but the principle remains familiar: the source stays editable where the diagram is used.
Create UML diagrams in SharePoint: What changes in everyday maintenance
| Previous workflow | With UML for SharePoint |
| Find the original source in another tool or folder | Open the source on the relevant SharePoint page |
| Edit the diagram outside SharePoint | Edit the text-based source inside the web part |
| Export another PNG or SVG | Generate the visual from the updated source |
| Replace the old image manually | Publish the page with the revised diagram |
| Check whether the text and image still agree | Review the text and diagram in the same editing flow |
The real benefit is not simply fewer clicks. It is reducing the distance between “the system changed” and “the documentation reflects the change.” That matters for system landscapes, integrations, processes and data models. An outdated connection or missing process step can lead to a false assumption during an incident, migration or onboarding process.
How to create a diagram directly on a SharePoint page
Modern SharePoint pages are built from web parts. Microsoft describes web parts as the building blocks used to add and configure page content. The same familiar SharePoint editing flow is used to add UML for SharePoint.
1. Edit the SharePoint page
Open the page where the diagram should appear and select Edit. Choose the position on the page, add a new web part and search for UML. Select UML for SharePoint from the results.
Screenshot 1: Finding UML for SharePoint in the web-part selector.
2. Open the web-part properties
Select Edit properties on the added web part. This opens the configuration panel where you define the diagram and how it should appear on the page.
Screenshot 2: Opening the UML for SharePoint properties.
3. Add the diagram source and page information
Complete the fields required for the diagram:
- Diagram title: a clear name that readers will understand
- Diagram description: its purpose, scope or any relevant limitations
- Diagram source: the text-based code used to generate the visual
- Diagram type: PlantUML or another supported format
- Output format: for example, SVG
- Visibility: whether the diagram should appear in mobile and email views.
PlantUML is the default type shown in the current configuration. PlantUML uses textual descriptions to generate UML and other technical diagrams. Its official documentation provides examples of the available diagram types and syntax. See the PlantUML documentation.
Depending on the setup, the web part may also require a rendering-server URL. During implementation, we define the rendering approach and useful defaults so teams do not have to make infrastructure decisions every time they add a diagram.
Screenshot 3: Diagram title, description, source, type and output format in the properties panel.
4. Review and publish the page
Check that the diagram is readable and matches the surrounding documentation. Pay particular attention to component names, connections, process steps and the diagram’s scope.
When everything is correct, publish the SharePoint page.
The next time a component, dependency or process step changes, return to the same page, update the source in the web part and publish the revised version.
Which diagrams does UML for SharePoint support?
Despite its name, UML for SharePoint is not limited to traditional UML diagrams. Through Kroki, the solution supports popular text-based formats for software, architecture, processes, data, networks and hardware. Kroki maintains a current catalogue of supported libraries, output formats and working source examples.
| Use case | Examples of supported formats |
| Software structure and interactions | PlantUML, Mermaid, UMlet, Nomnoml |
| Enterprise and system architecture | C4 with PlantUML, Structurizr, D2, GraphViz |
| Processes and sequences | BPMN, ActDiag, SeqDiag, BlockDiag |
| Data and technical structures | DBML, ERD, Bytefield, WaveDrom |
| Networks and hardware | NwDiag, PacketDiag, RackDiag, Symbolator, WireViz |
| Other visualisations | Ditaa, Excalidraw, Svgbob, Vega, Vega-Lite |
The best choice depends on what the diagram needs to explain. A sequence diagram may work well for an integration flow, while C4 or Structurizr may be more useful for a system landscape. Do not try to offer the longest possible menu; make the diagram types your teams actually use easy to select and maintain.
How to use a diagram type that is not included by default
Commonly used formats can be provided as predefined options. If the format you need does not have a ready-made Rocketta template, the Kroki examples provide a practical starting point.
- Open the Kroki examples page.
- Find the required diagram library.
- Open its working example.
- Copy the example source, not the rendered image or generated URL.
- Open the UML for SharePoint properties on your SharePoint page.
- Select the corresponding diagram type.
- Paste the code into Diagram Source.
- Replace the example content with your components, relationships or process steps.
- Review the result and publish the page.
This approach gives teams working source code to adapt. They do not need to learn every diagram language from an empty screen.
A text-based editor, not a drawing canvas
UML for SharePoint is a text-based diagram editor. Components and relationships are described as code, and the web part turns that source into the visible diagram. It is not a traditional drag-and-drop canvas with freely positioned shapes. That distinction should be clear before implementation.
For technical documentation, the text-based approach has practical advantages. The source remains editable, individual changes can be made precisely, and the diagram can be generated again without searching for a separate design file.
The web part does not need to replace every specialised modelling tool. It is most useful when the diagram belongs to a SharePoint page and should be maintained together with the documentation around it.
Three things we clarify during implementation
Adding the web part takes only a few steps. Making the workflow useful over time requires a few additional decisions.
- Which formats should appear by default?
A short selection based on real use cases is easier to work with than a long list of every available format. Architecture teams may need C4, PlantUML and Structurizr. Process owners may rely more on Mermaid or BPMN. Additional Kroki formats can still be added when required.
- How should rendering be configured?
The rendering endpoint and output defaults should be agreed for the environment. This avoids asking every person who creates a diagram to make the same technical decisions again.
- What should trigger a diagram review?
The diagram should be checked when the documented reality changes. Typical triggers include:
- adding or removing an integration
- changing an approval or business process
- retiring an application
- changing a system dependency
- completing a migration phase
- updating a data flow or data model
This is where the shorter editing path matters. If the diagram can be changed on the same page, it is more likely to be reviewed together with the text.
Where editable SharePoint diagrams are most useful
UML for SharePoint can support:
- system and application landscapes
- integration and dependency overviews
- sequence, component and class diagrams
- process and workflow documentation
- migration documentation
- data flows and data models
- network and hardware documentation
- technical onboarding pages.
The common requirement is simple: the diagram is part of the documentation, so it should be possible to update both in the same place.
Conclusion: How to create UML diagrams in SharePoint
A static diagram can look perfectly professional while showing a system or process that no longer exists. The problem usually becomes visible only when someone tries to update it and discovers that the source file, original tool or person responsible cannot be found.
UML for SharePoint keeps the text-based diagram source on the SharePoint page. Teams can create the diagram there, return to the same source when something changes and publish the updated visual with the surrounding documentation.
For teams familiar with text-based diagrams in Confluence, that means the move to SharePoint does not have to mean a return to static screenshots.
