Yes. Coach views run in the browser as the logged-in user, so XMLHttpRequest / fetch to the BPM REST API works with the session cookie - no HTTP POST form and no service flow needed for GETs:
// working example (BPM 8.5.7 / BAW): current user's open tasks via the search API
var _this = this, xhr = new XMLHttpRequest();
xhr.open("PUT", "/rest/bpm/wle/v1/search/query?organization=byTask&run=true&filterByCurrentUser=true&size=50&condition=taskStatus%7CReceived", true);
xhr.setRequestHeader("Accept", "application/json");
xhr.setRequestHeader("BPMCSRFToken", window.__csrf || ""); // BAW 20+ / CP4BA: token from POST /bpm/system/login (GET needs none on traditional)
xhr.onreadystatechange = function () {
if (xhr.readyState !== 4) return;
if (xhr.status === 200) _this.context.binding.set("value", JSON.parse(xhr.responseText).data.data.map(function (t) { return { id: t.taskId, subject: t.taskSubject, due: t.taskDueDate }; }));
else _this.context.element.textContent = "Error " + xhr.status;
};
xhr.send();Limits and rules: (1) same-origin only - other hosts need CORS; (2) the browser user must be allowed to do what the call does (no elevation - use a service flow when the call needs a technical user); (3) non-GET calls need the CSRF token on BAW 20+; (4) BPM's own REST API is fine, but calling external systems from the browser exposes their URLs and credentials - route those through a service flow; (5) prefer the UI Toolkit Service Call control for anything that already exists as a service flow - it handles context roots (important on CP4BA), CSRF, busy indicators and errors. The pattern "coach view calls REST" is what the Process Portal itself does, so it is supported and stable across releases.
References