title: CQ5 / AEM5.6 Workflow: Access workflow instance properties from inside OR Split
body: <p><strong>TL;DR version:</strong></p>
  
  <ul>
  <li>In CQ workflows, is there a difference between what's available to the <em>OR Split</em> compared to the <em>Process Step</em>?</li>
  <li>Is it possible to access the /history/ nodes of a workflow instance from within an OR Split?</li>
  <li>How?!</li>
  </ul>
  
  <p><strong>The whole story:</strong></p>
  
  <p>I'm working on a workflow in CQ5 / AEM5.6.</p>
  
  <p>In this workflow I have a custom dialog, which stores a couple of properties on the workflow instance. </p>
  
  <p>The path to the property I'm having trouble with is: /workflow/instances/<code>[this instance]/history/[workItem id]/workItem/metaData</code> and I've called the property "reject-or-approve".</p>
  
  <p>The dialog sets the property fine (via a dropdown that lets you set it to "reject" or "approve"), and I can access other properties on this node via a process step (in ecma script) using:</p>
  
  <pre><code>var actionReason;
  var history = workflowSession.getHistory(workItem.getWorkflow());
  
  // loop backwards through workItems
  // and as soon as we find a Action Reason that is not empty
  // store that as 'actionReason' and break.
  for (var index = history.size() - 1; index &gt;= 0; index--) {
    var previous = history.get(index);
  
      var tempActionReason = previous.getWorkItem().getMetaDataMap().get('action-message');
  
      if ((tempActionReason != '')&amp;&amp;(tempActionReason != null)) {
          actionReason = tempActionReason;
          break;
      }
  }
  </code></pre>
  
  <p>The process step is not the problem though. Where I'm having trouble is when I try to do the same thing from inside an <em>OR Split</em>.</p>
  
  <p>When I try the same <code>workflowSession.getHistory(workItem.getWorkflow())</code> in an OR Split, it throws an error saying workItem is not defined.</p>
  
  <p>I've tried storing this property on the payload instead (i.e. storing it under the page's jcr:content), and in that case the property does seem to be available to the OR Split, but my problems with that are:</p>
  
  <ul>
  <li>This <code>reject-or-approve</code> property is only relevant to the current workflow instance, so storing it on the page's jcr:content doesn't really make sense. jcr:content properties will persist after the workflow is closed, and will be accessible to future workflow instances. I could work around this (i.e. don't let workflows do anything based on the property unless I'm sure this instance has written to the property already), but this doesn't feel right and is probably error-prone.</li>
  <li>For some reason, when running through the custom dialog in my workflow, only the Admin user group seems to be able to write to the jcr:content property. When I use the dialog as any other user group (which I need to do for this workflow design), the dialog looks as though it's working, but never actually writes to the jcr:content property.</li>
  </ul>
  
  <p>So for a couple of different reasons I'd rather keep this property local to the workflow instance instead of storing it on the page's jcr:content -- however, if anyone can think of a reason why my dialog isn't setting the property on the jcr:content when I use any group other than admin, that would give me a workaround even if it's not exactly the solution I'm looking for.</p>
  
  <p>Thanks in advance if anyone can help! I know this is kind of obscure, but I've been stuck on it for ages.</p>