One area where we're interested in a broader feature set from Workiva's ESG solution is in the "disclosure management" domain. I'm wondering if anyone has any general or specific feedback or ideas on this topic.

For example, our users are frequently trying to answer some of these highly related questions:

1. Do we disclose this metric publicly? Where? This is a question some of our users, or other ESG stakeholders, are often trying to answer: whether we are publicly disclosing a certain metric, and if so, where it has been disclosed. A key point is that often the medium of disclosure is not a report produced by Workiva; it could, for example, be on our public website or in financial statements not produced in our Workiva ESG workspace. But instead of tracking this information in an off-Workiva spreadsheet, it would be great to track it in the ESG Program. Ideally, they want to be able to go straight from the metric (e.g., in the ESG Program) to see a list of such destinations.
2. How do I know what the context of this metric's use is / will be? For metric value assignees/approvers, sometimes in addition to reading a metric description or instructions, it is useful for them to see how a metric value will be used; i.e., to see the context where the value will be inserted, when they are providing the value. (This is especially relevant as, in our organization, reports' structure and/or copy may often be drafted before a metric value is provided, and especially with text metrics this can help elucidate the input required.) Beyond this, frequently a metric value assignee or approver in our organization is the "metric owner," and has some level of authority to approve/deny the use of a metric value and needs to review the wording/context where it is used (to avoid misrepresentation, etc.) before they approve the use. Right now this involves a business process to ensure that, every time a metric value is linked into a document, the metric "owner" (assignee and/or approver) is notified and granted access to review the document and provide input/approval. It would be nice if this were more automated; e.g., whenever an ESG metric value is linked into any file, the metric "owners" are notified and have an ability to approve/deny or automatically review the context and provide feedback.
3. Where can I track/find or update whether and where a metric is allowed to be disclosed? How can I request approval for this metric to be disclosed / can I get permission to disclose this metric to a certain audience for a certain reason? Who approved this metric value to be disclosed publicly? In order to have a comprehensive inventory of ESG metrics we are tracking, our ESG program needs to contain metrics not approved for public disclosure in addition to those that are. This could include metrics for internal use only, metrics that can be released under NDA, or other metrics that are only released upon request and not proactively shared. Moreover, even with public metrics, there is sometimes a parallel process outside of Workiva metric data collection to propose/review/approve/log that a metric can be shared publicly (or under NDA, or to a certain audience for a specified need) or audit who gave the approval. This is related with point #2 above in that there is basically a process flow of people who want to use data in a report pleading their case to a metric owner who must determine if that metric can be disclosed in that context, with key aspects of the request and approval ideally logged and auditable. Hence these requests and approvals are tracked in an off-Workiva platform, when the desire is to be able to use the ESG Program for more of this.

Although these are wide-ranging they all seem to be related in that they involve (1) tracking details of how a metric is disclosed/used (beyond simply its type, dimensions, values, etc.) in the ESG Program and (2) better visibility end-to-end of how/where a metric is linked/disclosed.

There are admittedly some partial solutions to these issues today. For example, the "links" sidebar offers a partial solution to seeing where a metric value is used, but it's an incomplete solution for several reasons. First, as ESG metrics are not linked directly to document(s) but rather are connected to Program, then connected into a Factbook, etc., it is impossible for a metric value assignee/approver to see where the metric will be is used via a Data Collection sheet or task. Moreover, even when looking in the Factbook to see where a metric value has been linked, that same metric value may appear in multiple places in the Factbook or even multiple Factbooks, with each link showing a different set of destinations. But perhaps the ESG sidebar seems like it could hold this information.

Program tags are also a partial solution. One issue we find is simply that tags can't be hyperlinked, and would probably be unwieldy if so, so it's hard to get very granular using tags to track where a metric has been published. Also, for it to be a "one-stop shop" to view where a metric is disclosed, the files in Workiva where the metric is used would have to be manually added, which would be duplicate effort.

Multiple ESG programs may be a partial solution to distinguishing "disclosure-ability" of metrics. E.g., NDA-only metrics could go in one program, and public in another, in order to enforce segregation. Of course, if a metric gets "promoted" to public visibility, one must migrate a metric over.

We would also like to explore the use of Custom fields at some point, or even Process tags, as we foresee these may be able to help (for example, program tags could be set up to match the value of a custom field, so via a two-step one could see which category of documents a metric should/can be / is used in.

One feature not currently available (to our knowledge) that might also help would be the ability to add custom fields (note: not necessarily the new "Custom fields" feature mentioned earlier, but just any new SQL fields) into the ESG Program and expose these fields in the program UI, or even in the Tasks UI, in addition Wdata. This could allow for the collection of information that is more structured than what would belong in, say, metric notes, but less structured than would be appropriate for program tags.