https://netsuiteprofessionals.com logo
Join Slack
Powered by
Trying to build an approval workflow/process where...
# suiteflow
d
Trying to build an approval workflow/process where the DOA changes depending on the amount of the requisition. Can you think of a way this could be done without scripting AND without the need to save the record before determing the first approver? I think it's relatively easy to do if the record is save first, but that's going to be a shitty experience for the user.
m
What is DOA?
e
If the amount of the req is not available without saving, then I don't see a way to do any logic without scripting
d
DOA = delegation of authority aka approval matrix
So, I thought of a way (that's the simple way) but I'm not a real big fan of it.
It would involve having the user select the first approver based on them knowing the DOA levels and just showing an error message if they select someone that's not in that group. It's more complex than that explanation, but would effectively do the job.
this is what we're going from and to:
m
oh i see. Yes as @Edgar Valdes said the transaction total amount is not avaliable until the record is saved so a script would have to be done to calculate it up in realtime.
You might be able to add a button to "Calculate Approver" that they click before saving
d
the current matrix has the transaction going through up to 6 levels based on amount; the new one is 2-3 approvers based on amount. it's a nightmare.
m
I could get on my soapbox about approval matrices.....I'll never understand why companies insist on the most complicated approval workflow, but then within weeks start asking "How ccan we work around all these approval steps??:
d
My plan is to have a field on the employee record that slots them in one of the levels shown; then have fields on the PR for each level that would filter to the applicable employees. then have the record creator pick the first (lowest level) approver and have the WF check that that field is populated.
haha you don't have to convince me
m
So the user needs to see who the next approver is BEFORE they save it?
d
the user would just have to select the next (first) approver before saving. they'll have a list of qualified people in the dropdown
m
oh I see, now it makes sense
Did they start asking about "What happens when someone is out of office for the week?"....LOL
d
haha good, i'm glad it's not only making sense in my head. it's already a broken matrix if you ask me, but they don't care yet...
m
Yeah I agree....again to my earlier point I've never understood why a simple manager or dept approve -> CFO -> CEO approval won't work
seems to cover all bases to me
d
because what happens when the record creator is a manager or director for an amount that's on the lowest level (under 25k)? then they have to select a junior associate as the first approver. makes no sense.
m
haha yeah
What if you did it in stages?
d
and i can't think of a possible way to solution something that is a variable number of approvers AND has to take that into account.
m
User enters the req and saves it...upon create use the go to record action to go to a custom record called "Assign Approver". This would open in edit mode and the would have to choose from the list of approvers.
Then when they save this record you update the approver field on the record
So use Create Record > Subscribe to Recrd > Go to record
d
problem with that is the record creator only selects the first approver; that approver then selects the 2nd approver. then (if applicable) that 2nd approver selects the third.
m
then since your custom record is a child record of the transation it can be used to update the main transaction because of the subscribe to record option
You could do it each time
then you would also have an approval audit trail as a sublist attached to the transsaciton
The UI would be a little strange as when they save it would redirect to a new page but wouldn't be an awful experience
d
i'm thinking about it
e
Don't get me started on approval workflows crying
😂 1
We use rules that take into account: 1. Requisition department 2. User department 3. Requisition amount 4. Custom record with amount brackets 5. Custom field on employees with user director and user vp 6. Custom fields on departments, with default approvers for director and vp brackets 7. A logic to avoid double approvals for the same users 8. Item category (prepayments has other rules) 9. Custom "return for correction" workflows
And more 😆
d
LMAO that might actually be worse than mine.
e
Up to 9 approvers in the higher amounts and special conditions
On the other hand, I have cleaner DOA in other areas, like Expense Reports
m
I’m trying to find my most impressive approval workflow so we can compare who’s looks more like a plate of spaghetti I had one with 37 states in it
😂 1
😨 1
lol
d
this is the one i'm amending:
only 21 states....weak!
BTW i think i've come up with a plan for my conundrum. Basically thinking I'll have a single "first approver" field on the form visible and then, based on the amount of the PR, feed that into the actual array. So I'll hide these (below) on the form initially, then when its saved will expose the applicable ones while hiding that initial "first approver" field.
e
I used to have the level number in the State description, but then some change is required and I don't want to rename all the states with the new sequence number
d
"User enters the req and saves it...upon create use the go to record action to go to a custom record called "Assign Approver". This would open in edit mode and the would have to choose from the list of approvers." Ok, I'm gonna at least try this out. I don't like my prior solution already...
e
We set the approver without user intervention. The combined rules of the WF search for the correct approver and set the field. In fact, the Next Approver field is disabled for requesters.
d
God, I wish I could do that.
The Beast is complete:
m
Haha this should be framed
😂 1
e
40 states what
I have a 41-step Approval Process... BUT!.... Split into 3 different chained workflows
d
Not sure if horrible design or great design... And most of these states have like 20 actions each.
e
The lack of a native Reject Reason pop-up is a huge one.
m
Yeah that is a huge bummer with workflows. I ended up making my own custom WFA for the pop up to collect a response because I needed it so much
It’s so much of a nicer UX
d
I justify the size of this because it's really kinda just 5 different flows.
e
And most of these states have like 20 actions each.
I normally: 1. Set values (next approver, custom 
approval level
name) 2. Send emails (to next approver, to requestor) 3. Lock the record 4. Show buttons (approve, reject, return for correction) 5. Run Scripts (to calculate the next approver by amount, department, current level, etc.) Even then there are like 10 actions, not 20 🙂
m
Yeah I wish NetSuite allowed you to copy states. It would make these so much faster. Most approval states are the same 10-15 actions repeated just with different values set
d
"Even then there are like 10 actions, not 20 🙂" Half the actions are making fields disabled. There are five potential approval paths dependent on the amount of the PR, and 2-3 approvers also dependent on that amount. So I'm doing a lot of disabling the non-applicable approver fields:
Here's one example:
Woo, I did just find some duplication and was able to delete 8 total actions lol.
✅ 1
e
Yep, the number of custom fields to be locked is high. One time I inherited a record with 45 custom fields and a Workflow for lock/unlock. It was a nightmare. I ended up removing the WF and creating a couple of scripts (ue, client) to loop all the fields and set them as available or not.
d
Sadly, I don't do scripting, so I'm always looking for ways around that limitation before I have to resort to calling on a developer.
85 Views
Open in Slack
PreviousNext
Powered by