GRStageReporter can throw nullpointerexception if sc_request processing is disabled and flow sets stage immediatelyDescriptionThe flows start on the sc_req_item insert via the "Start FlowDesigner Flow" BEFORE business rule. Because this is a BEFORE rule the flows are actually running before the DB insert operation has occurred. Normally the sc_request flow processing would ensure that the sc_req_item is already in the DB by the time its flow runs. However, in this particular case, sc_request has been modified such that it no longer works the way it does OOB. Note that Flow Designer is designed as an AFTER engine, and is not intended to operate on records that are not yet in the DB. So technically this edge-case is completely unsupported. The case this originated from was resolved by telling the customer to restore the sc_request level processing so that the sc_req_item records exist before the FD flows for them start.Steps to Reproduce 1. install the attached update set. this should:a) remove the wf_workflow "Service Catalog Request" - there should be no workflows that run on the insert of an sc_request recordb) add an FD flow with a service catalog trigger that sets a stage immediately (before the first Action in the flow) - flow name = GrStageReporterc) modify the sc_req_item BR "Start FlowDesigner Flow" to make it run on insert and removed the request.state == approved part of the conditiond)add a catalog item = GrStageReporter that uses the FD flowEnd result is that there is no sc_request level processing and the FD flow for the sc_req_item record is started on the insert of the sc_req_item records.2. order the GrStageReporter itemExpected: the FD flow runs sucessfullyActual: the FD flow failsWorkaround1. We can create sc_request workflow in place (Start -> Approval Action -> End) and restoring the (BR Start FlowDesigner Flow) to OOTB2. Remove setting a stage in the FD flow until after the flow hits a wait state (Approval, Timer, Wait for Condition)Related Problem: PRB1508938