I already do than in many different situations, but for repository entries I use that approach primarily for "temporary" status tracking or data that's actually relevant to the lifecycle of the document, and it's not really the ideal solution for these types of scenarios where the data is more relevant to the process itself rather than to the document.

In my example:

1. The information is only relevant at the "high level" because it doesn't impact how the document will be stored or processed afterward.
2. If the documents are rejected, they are deleted immediately, so all the data would be lost.
3. The documents are only in this repository temporarily while they are being reviewed/processed so once they move into the permanent repository, get printed, etc., those copies would eventually be deleted and the data would again be lost.
4. Each document could have multiple pages that get resized so I'd have to track a multi-value field for every document just to hold information that really only matters on high level (how often does this happen) kind of scenario.
5. At the workflow level, the documents are all grouped to a single submission/submitter so the data is more useful/actionable. After processing, each document (even from the same submission) can take any number of different routes.
6. Running a complex search in the repository just for that metadata is overkill when all I really want to do is search Workflow for instances of ___ workflow with a "message" between certain dates.

Additionally, that was just one use case. I have a dozen other workflows where I'd like to trigger searchable messages based on certain events because they are more important to me than the other errors/warnings that might be generated.

As an example, if an email activity fails because of a temporary issue, a try catch will handle that and allow it to recover so I don't really care about those unless they happen unusually often, but the error is still logged regardless.

On the other hand, when email fails because of a missing/invalid email address, or the email server kicks it back because the domain wasn't whitelisted, then that is something I do want to investigate, but from the Workflow history an error is just an error so I can't single those out.

As another example, if a workflow is interacting with an API and gets an "intermittent" error like a 500 general server error or 408, it can just wait and try again with a try-catch, but it still generates an error message.

On the other hand, if I get a 404 error, or I get a response with model validation errors, that is something I want to flag and investigate because although they are all errors, some are much more unexpected/noteworthy. 

Well I suppose another workaround I often do is have blank entries created in a hidden workflow folder, and use this for tracking internal data.

In the designer you can search by Activity Name, so I suppose you could use End Workflow activities with specific names and hold the data in the Reason textbox. This would be an alternative to enabling Business Process just to use the status field.

At the end of your workflows, you would just see if you need to call one of these End Workflows and call it before the workflow ends naturally.

Jason, would the ability to further filter search results on a provided Error/Warning/Message string address what you're looking for here? I suspect that would be far earlier for us to implement than a new message type. Likely minor WF Designer UI change w/ additional SQL query constructor parameter vs core Workflow Server event logging code updates plus WF Designer UI updates.

Hi Sam,

Yes, now that you mention it, being able to search/filter the contents of the messages would provide similar functionality.

A single filter/field that can be applied to all of the selected logging types would be very helpful for these situations.

Honestly, that might actually be more helpful overall since the goal is really to hunt down specific types of errors/warnings/messages and the filter would be much more targeted than what I described.

That would also help track down instances stopped by an End Workflow event or manually from the designer since those events and their given reason gets added into the logged error/warning.