Organizing knowledge in Confluence with Properties: a chat with Seibert Group’s Partner Manager

[#1]

At Seibert Group, collaboration and organization go hand-in-hand. As an Atlassian Platinum Partner and powerhouse behind popular Marketplace apps like Linchpin and Aura, Seibert Group helps teams work smarter with Confluence, Jira, and beyond. But even internally, organizing vast information across teams can be a challenge — especially when it comes to managing product enablement resources.

I caught up with Carolin Kohnert, Partner Manager at Seibert Group in the Solution Partner business unit, to learn how she solved a classic Confluence chaos problem using the Properties app. With a smart system of battle cards and customized property groups, she brought structure, accessibility, and visibility to the team’s partner enablement efforts.

Q: Carolin, can you briefly describe your role?

Carolin: I'm the Partner Manager for our Atlassian Marketplace ecosystem. I manage relationships with app vendors and help align their goals with our internal teams. I make sure the right people at Seibert Solutions have access to the right partner information — whether that’s for account managers, consulting projects, or license sales.

Q: You had a problem around app enablement materials. What was the challenge?

Carolin: When I joined the vendor management team, the information was decentralized: lots of different Confluence spaces and pages, shared Google Docs, external databases, and individual heads. I had a lot of resources from all of the app vendors available and no place to organize it. I quickly became the go-to person for questions, and it was clear I was becoming a bottleneck. That’s when I knew we needed a better system.

Q: How did Properties help you tackle that?

Carolin: I started by mapping out what kinds of information we really needed and how people would want to access it. That led me to try out the Properties app, and it clicked right away. I created battle cards in Confluence, one page per app, and used Properties to add structured fields to each one.

I also created one page per Marketplace partner to summarize key information.

Instead of hoping Product Marketing Mangers would use the right kind of data in a table and use the native page properties macro, with Properties I could define exactly what kind of information went where. For example, some fields were short text (like the vendor name), others were dropdowns (like the product status), and some were links (like a URL to the vendor hub or internal resource). I had full control over the data type, which meant better consistency and easier updates.

Q: Can you walk us through what a battle card looks like, and how you decided which Properties to use?

Carolin: Definitely. I focused on the needs of our sales team, since they’re often the ones using these cards. Each battle card includes:

• App Name (short text)

• Vendor Name (short text)

• Product Focus Area (custom dropdown)

• Elevator Pitch (long text)

• Partner Info Link (link field)

• Internal/External Contact (person field or dropdown)

• Status (custom dropdown: “In Use,” “In Progress,” “Outdated”)

• Keywords (tag field for filtering)

• Last Updated (manual date field)

I created these fields as a custom Properties group just for battle cards. That way, any page using this group stays consistent, and we don’t have people inventing their own formats.

Q: How is the information on the individual pages available in the Properties report?

Carolin: I also created a Properties report so the team can browse the summarized information in either a table or card view — whichever suits their style. When I set up the Properties Report, I limited it to a specific Confluence space where the battle cards live. This was super important. I didn’t want the report pulling in data from unrelated pages or projects. That way, only relevant content appears in the report — no clutter, no confusion.

Q: You prefer the card view. What do you like about it?

Carolin: I’m a very visual person, so I like the card view because it makes the content feel digestible and interactive. Each card looks like a mini-profile — you can quickly scan for keywords, click links, and see who's responsible for what. It's great during sales calls when you need fast answers.

That said, some teammates prefer the table view for more data-heavy scenarios — which is totally fine! The flexibility is a huge win.

Q: Any standout features you appreciated about Properties?

Carolin: The custom field control was huge. I didn’t want people typing random text into a table — I wanted to make sure, for example, that the status field was selected from a dropdown so we could filter it later. Properties let me define those controls and update them easily.

I also love that the report view is interactive. If someone updates the elevator pitch or changes the status to “Outdated,” it shows up right away in the report — and with the click of a button, teammates can jump to the full page or contact the right person. It’s seamless.

Q: Any advice for others looking to do something similar?

Carolin: Don’t overthink it at first — just define a few key fields your team really needs. Start with a limited space or page type, and set up a custom Properties group. Use the report feature to centralize everything. Once you’ve got it rolling, you can always evolve the structure over time. I’m still tweaking and expanding ours!

Also, remember to give your Properties report clear filters. Otherwise, it can pull in unrelated data and get messy. Confining it to a dedicated space helped us keep things tidy.

Final Thoughts

With a smart mix of structured content, custom fields, and filtered views, Carolin turned Confluence into a centralized, self-serve vendor portal.

Have a similar use case or curious about getting started with Properties? Drop your thoughts in the comments — and let’s swap some Confluence tips!