Possible to delay submission of a form via Portal?

[Shane J]

Is there a way I can put what equates to a delay after submission of specific forms in the Portal?

I have delay of 1 second in my main REQ workflow in order to color code RITMs with the same parent REQ (without the delay it doesn't work).  So right now the customer's list of tickets loads immediately after submission but without the color (if they gave it another second and reloaded it would be fine).

If it's a matter of delaying every submitted form by a second, I think I could live with that.

[LaurentChicoine]

Hi, have you considered putting your color logic inside the widget you are using to display the RITMs? Instead of adding a color attribute in the database, you could compute the colors when you display the widget, that way you don't need the workflow to run to add your colors.

[Shane J]

I'm not sure how that would work.  As it is now, the color of the row in the ticket list is driven by a hex color set on the RITM itself which the widget does reference.  That color field gets valued as part of the process I have setup in the workflow, and in turn is used by future RITMs that are entered to determine what color they should be (if anything).

I don't know how something 'permanent' like this would work in the widget?

[LaurentChicoine]

I really think you should remove your delay in your workflow. I'm guessing you are using a 1 second Timer. The timer is actually working async which means it creates a record in the sys_trigger table that is then being runned by a job processing these sys_trigger records. If your instance is overloaded with async jobs, these might be delayed and your user could have to wait more than 1 second before the color is added to the records.

Depending on your rule color, you could generate the color based on the REQ number so that you don't need to store the color in a different attribute.

Other than that, have you considered adding the colors using a business rule instead of the workflow (that might remove your limitation that requires to add a delay). If you want to try with a business rule, make sure you understand the way request/requested item creation works: Which came first, the Request or the Requested Item?

I think running an after insert business rule on the request record could work but you would have to try.

[Shane J]

That was how I had it originally setup but couldn't get it to work.  There have been some extensive changes to how I have it working in the workflow, so it may be that I could try moving it back to a BR instead.

In regard to this:

Depending on your rule color, you could generate the color based on the REQ number so that you don't need to store the color in a different attribute.

I have it setup right now to reference a custom table of color records I setup - so I ensure that colors too similar don't get used together and that the text in the rows is still readable.  I don't know if I have the time to get into a formula that translates RITM00001 into color #f7f2f3 (terrible example I pulled out of nowhere) but maintains readability as well.  Don't get me wrong, I love the idea, but having the time to execute could be an issue. 

[Shane J]

Well Laurent you got me to move everything to BR's but I'm still having an issue with timing (I've got a dependency on records created in earlier before BR's that are not coming across properly when referenced in after BRs). 

It may that I just need to look at this from a different angle.  Either way, I'm still working on it...