Selecting on information on a table can be done by filtering. Filters may reduce the amount of columns and the amount of lines. You can have controls where you type and automatically prune the table.

How can we approach this requirement using single sourcing?

The page holding the contact information for a person can be based on a blueprint to make it easier to add new members and provide the information that is most relevant to the team. A blueprint is therefore a tool to support authors to compile similar information in a similar way and it shows the author which information is typically expected on such a page. This guidance is implicit with the table approach. The format and layout is defined by the order and number of columns of the table.

Information that should only be visible to team members having certain roles could be added on separate pages. The access to these pages is restricted by the wikis access control and are transcluded on the public page. Therefore the transclusion will only happen if the user has sufficient access to the restricted information. This feature is difficult to master with a table approach. You would need to have a tool that allows to grab information from an alternative location and render it into the page at request time. This is what transclusion does with Confluence tools.

You can add information in different formats. For instance the telephone number in form of its extension and in full format. You may also define different type of team members where different types of information is relevant.

To automatically render the information of all team members in tabular form, use the Display Table Macro. This macro allows you to query for team members with certain properties and select to show only the personal information that is relevant to your use case. That is you have the information of team members in one place and then have multiple views on this information by using the Display Table Macro.

With the table approach this table is automatically provided. But since it is hard wired, there is only one view on that table (with some considerable variations if you add code for filtering and sorting to that table).

To reference a single member you would need to reference a single line in the table. This can be done with a named anchor, but this is usually troublesome.

If you have each team member on a separate page, the URL to that page references the team member. Via this URL all information about the team member that is relevant to the team is accessible. This URL can be easily added to other documents to create a web of information.

Since the URL points to a page in Confluence, changes to the name of the page will automatically update all references. This is not the case for named anchors. If the named anchor changed, the references are not updated automatically.

In tabular form it is often unwieldly unwieldy to have short information like a name in the same line as a list of special interestes interests or other multi-line notes. It makes the table less readable since all cells in a row need to have the same height. And although the height of rows may differ, a table with rows of the same height is usually more pleasent pleasant to read.

If the information for a team member is on a separate page, any information can be added. The projectdoc Toolbox distinguishes between Document Properties, which are typical single line and used to filter on team members for a search result and Document Sections which comprise multiple blocks like paragraphs or tables. Since each view selects on information, the information can be rendered in the most appropriate layout.

Having defined fields of expertise on could also collect names of team members who are proficient in that field. That is by clicking on an expertise on a team member page, the user would have access to a list of team members that also have knowledge in that area.

If you document projects and link to the people who are part of the team, a history of projects can be automaticall automatically rendered on the team member pages. The same is true for topics the team members are authors of if they are mentioned as as authors on the topic page.

The page for contact information of a team member becomes a portal to related information by itself.