运用工作流系统之后，流程的每次流转每次执行都会被记录下来，直到流程结束。这些被记录下来的记录就是流程实例的运行轨迹。运行轨迹的每条记录都会有一个主键id，用于唯一标识这条记录，这个主键id，就是流程实例轨迹id。
每个流程实例都有自己的运行轨迹，这个运行轨迹可以用列表也可以用图形的方式来展现。
流程实例的监控，大多是监控这个流程运行的轨迹。通过二次加工和定制开发，或再加上定时器的功能，可以做一些居于图形的实时监控。
如，直接图形化显示监控流程的运行轨迹变化；点击图例，输入一些值（业务数据），作用于流程，并使得流程运行轨迹发生变化等。
流程实例如果执行循环路由，或自由回退等，反复的执行同一个步骤，如验收时，发现问题，返回重做，反复的返回重做（类似项目软件开发，需求总变化，反复的重做）。这样一个步骤就会执行了很多次，每次执行的时候，都会记录一条运行轨迹记录。如果客户希望通过监控流程运行轨迹，能清楚的看到每次重做时，都重新做了那些业务，这样就需要将流程实例轨迹id和业务记录一一关联上，在监控流程实例轨迹时候，通过轨迹id，就能取出业务记录了。这样就能清楚的还原当时的修改。
如果将流程轨迹id和业务记录关联上，业务表也应该是一个类似的日志表，能记录多条业务信息，在eworkflow的通用审核表中，就增加了轨迹id( trace_id)这个字段，当发生一次审核的时候，就往通用审核表中增加一条记录，并记录上trace_id。审核结果查看时，就根据trace_id关联出通用审核表中此审核记录，将审核结果和审核意见取出显示。 这种通用审核，不论多级审核，都无需再做表结构等的设计，多一级审核即多一条记录，后期有需求变更或流程流转的修改，要修改流程节点时，多增加一级审核或去掉一级的审核都很方便。
流程引擎在获取每次运行的节点时，都可以将流程轨迹id取出，送到节点上关联的表单中，在业务表单中，可以取到此轨迹id（trace_id），根据业务情节的需要，合理的运用此流程轨迹，实现更多的业务。