RSS

Confluence vs. SharePoint - Part 1: Overall structure

In this post we look at how content is structured in both Confluence and SharePoint.

Confluence

When looking at a Confluence page the basic structure looks like this:

A Confluence page

The following parts make up a Confluence page:

  • Page Content, including
    • Versions
    • Inline Comments
    • Inline Tasks
    • @-Mentions
    • Macros
  • Attachments, including
    • Versions
    • Comments
  • Footer Comments
    • like page content…
  • Restrictions
  • Metadata, including
    • Title
    • Creator, Author
    • Creation Date, Modification Date
    • Likes
    • Labels

Each page lives in a Confluence space where each space can contain hundreds, thousands, or even tens of thousands of pages.

Pages within a space usually form a hierarchy. This means there are parent pages, child pages, and leaves, like a tree:

A Confluence space contains many pages

Access to pages can be restricted at each level of the tree, which also affects all child pages. If a user is not allowed to access a parent page, they cannot access any of the child pages as well.

Confluence can have many spaces. A typical instance has dozens or a couple of hundred space, but there’s also instances with a couple of thousand spaces.

The following parts make up a Confluence space:

  • Pages
  • Metadata
    • Title
    • Description
    • Archived or not
  • Restrictions

Spaces have no hierarchy:

Confluence organizes content in spaces

SharePoint

While Confluence consists of spaces, SharePoint consists of sites, which serve a similar purpose.

The following parts make up a SharePoint site:

  • Lists (note: those are like a table)
    • List Items
      • Item Data in List Columns
      • List Item Permissions
    • List Permissions
  • Document Libraries (note: those are like a drive or folder)
    • Files
      • File Metadata in List Columns
      • File Permissions
    • Document Library Permissions
  • Site Permissions
  • Apps

A SharePoint site

Some SharePoint document libraries are “special” in that they serve a specific purpose. With regard to pages, there’s the Site Pages library and the Site Assets library.

All SharePoint pages are stored in the Site Pages library. For SharePoint, pages are just files with some metadata. There is no page hierarchy and all pages are stored flat in the Site Pages library.

Page attachments are stored in the Site Assets library, in a folder that belongs to the page. Each page has its own folder.

When setting the permissions for a SharePoint page, SharePoint takes care of setting those permissions on the page’s folder as well.

How does it map?

Often Confluence spaces are compared to SharePoint sites.

I’d say this is a fair comparison, when focusing on wiki functionality.

Confluence spaces and SharePoint sites have some things in common. Both:

  • have a title and description
  • have owners
  • can be access restricted to users and groups
  • contain wiki pages and files
  • have their content indexed by search
  • have no strict technical hierarchy (bear with me on this one)
  • have their permissions inherited by pages, but pages can also have their own

Confluence pages and SharePoint pages also have some things in common. Both:

  • support the basic text formatting capabilities, like bold, headings, tables, images, etc.
  • can be created from templates
  • can have sections to structure page content
  • can contain “blocks of functionality” - macros in Confluence, web parts in SharePoint

Here are the areas where Confluence and SharePoint differ:

ConfluenceSharePoint Online
pages form a hierarchy (with parent and child pages)pages are flat, without a hierarchy
page breadcrumb navigation above pagesno page breadcrumb navigation
pages have attachmentspages have associated files in a special folder (we can make it look like attachments using a web part)
attachments (files) are bound to pagesfiles are stored in document libraries and linked to by pages
pages seem a bit better suited for documenting knowledgepages seem a bit too much focused on presenting content nicely
macros can be nestedweb parts cannot be nested
page restrictions have a hierarchyitem level permissions for pages have no hierarchy
rich app marketplacemarketplaces are not Microsoft’s strength
pages support @-mentioning other usersno @-mention support on pages
comments under pages with rich formatting, deeply nestedplain text comments under pages, 2 levels
inline comments on pagesno inline comments
inline tasks on pagesno inline tasks
integration with Jirano integration with Jira
pages can easily be moved to other Confluence spaces (due to their self-contained nature)pages cannot easily be moved to other SharePoint sites (at least not without breaking links or attached metadata)

Confluence Cloud introduces some new restrictions compared to Confluence Server and Data Center, for example with regard to formatting content and nesting macros.