While fiddling with the workflows in a freshly minted CRM Online organization trying to find out what else we can do now that we couldn’t do before (like OR condition, this sort of stuff), I came across of this new, interesting and very much undocumented field called Traversed Path:

After playing with it for X minutes I can report that it returns a comma-separated list of GUIDs of the stages of the business process flow that the entity “went” through. Why would we need a list like that and couldn’t we just figure that from the flow definition? Not with the awesome new feature like business process flow branching where some parts of the process may or may not be executed.

In a nutshell, it’s a less glamorous, less visible and most certainly less developer-friendly server-side counterpart of getActivePath client-side function. If this attribute was ever defined in the documentation then definition probably would have been (to borrow and paraphrase):

The read-only TraversedPath attribute represents stages currently rendered in the process control based on the branching rules and current data in the record.

The actual traversed path that is used by the system is in BusinessProcessFlowInstance entity. It also has a TraversedPath attribute but this one is not accessible as this entity marked as internal. The <entity>.TraversedPath attribute only stores an entity specific copy and it is used only to understand which stage of the entity to show as selected stage when the record is open.

I am not convinced though that this “surfacing” of the path is intentional (it’s not possible to hide or suppress attribute from the metadata though) and won’t disappear or at least marked as “internal use only” at some point in the future documentation. Until then, go for it (read-only!) and let us know if you find it useful.