Hello, within an LCM Access request workflow, I have added an intermediary step that creates a form when a user requests a specific role.
The WorkItem with the Form is being created successfully, but the item does not appear in the user’s “Work Items” List. The only way to access the work item is by going to the access request and then clicking open on the item in the interactions tab.
Once the user clicks submit on the form, the workflow continues as expected. My only issue is that the WorkItem does not appear in their work item list.
When I view the WorkItem in Debug, the “State” is null. Is there further information I need to provide in order to make this form recognized as an actionable work item?
can you please share your workflow xml if you can?? also, when you go to access request page, and see the form, do you see workitem.jsf page it is calling??
Hello Brandon. Since the WorkItem is being created and the form opens and submits successfully, I would not manually set the WorkItem state.
I would first check the actual owner on the persisted WorkItem in Debug. My Work > Work Items only shows items assigned to the logged-in identity or a workgroup they belong to. Please verify:
owner is the expected IIQ Identity or workgroup.
The user does not have an active forwarding configuration, and the owner has not been reassigned because the identity is inactive.
There are no filters applied under My Work > Work Items
Form itself is a supported WorkItem type, so workItemType="Form" may not inherently a problem. If those look correct, could you share the WorkItem XML from Debug, especially the owner, type, handler, renderer, and attributes? That should make the difference much easier to identify.
hi @brandonkinnick Once workitem is created it will appear in workitem list if you want to use form
Then use above code , i suspect something wrong when u use the other way or some issue on wokritem may be some error. So please narrow down this issue or may be one time server restart will help
One thing I would test is creating the same step with workItemType=“Approval” while keeping the custom workItemForm; IIQ supports attaching a custom form to an Approval WorkItem, and this would tell us whether the issue is specific to how the Work Items page is handling the Form type.
I’d also compare this XML side-by-side with an OOTB Form/Approval WorkItem that does appear under My Work > Work Items, particularly the targetClass, targetId, and targetName fields, since those are absent from this WorkItem.
If changing only the type to Approval makes it appear, then the workflow persistence is fine and the problem is likely in the Work Items list/query or UI handling of this particular Form WorkItem rather than the form itself.
That comparison should narrow this down much faster than changing the WorkItem state.
Thanks, the XML helps. The persisted owner is correct, and State=null on this pending item does not by itself indicate a problem. type="Form" is supported, but which WorkItem types appear in the Work Items table can be configurable (Types of Work Items).
I would check the actual My Work > Work Items request in DevTools > Network and search for WorkItem 0000002333:
If absent, check whether Form-type WorkItems are included in this environment.
If the request fails, check the IIQ log for WorkItemListService errors.
If returned but not displayed, look at the UI/UIConfig side.
If Form items are enabled and the request is clean, test the same custom form as an Approval WorkItem in DEV. If that appears, it narrows the issue to Form-type handling (Approval Steps). I would still avoid forcing state or adding workItemTarget* until we see what the list request is doing
@brandonkinnick Try setting the workItemType to Approval (keep workItemForm, workItemFormBasePath, and the renderer as is), and populate the tracking args in your workitem(identityRequestId/workItemIdentityRequestId, workItemRequester, workItemDescription, notification/escalation templates)., so it’ll become a trackable inbox item rather than a bare form.
Switching the type to Approval should fix, please try; i don’t think manually setting State would help.
Hello, thank you all for your replies. I’ve set the ‘workItemType’ to ‘Approval’ and set the workItemIdentityRequestId field, but unfortunately nothing has changed.
I’ve found an existing Form WorkItem that was generated from a Workflow and correctly appears in the work item list. Here is the XML for that.
One difference I am seeing is that the Form has type=“Workflow”. I tried setting this manually in the Workflow ``form.setType(Form.Type.Workflow)` and it applied the type but I am still seeing no difference in behavior.
OK, on further investigation the work item DOES appear in the Work Item list. The list was being filtered by WorkItemId and not Created date, which is why the item was not appearing at the top. The issue is resolved, thanks!