Can you share screenshots of your Workflow Sublist...
# suiteflow
k
Can you share screenshots of your Workflow Sublist action group and your action within it?
b
message has been deleted
only other criteria is that location (main) is not empty
k
Can you share the actual set up on them as well?
so that shows me they are part of a sublist action group.
but that's all
b
message has been deleted
message has been deleted
that's the entire WF
just those 2 sublist actions, which is how i understand you have to configure it to work on line level data
k
The context being suitelet seems odd to me
b
oh, that's cuz the order came in from our website and the orders come into NS using a suitelet
k
why not just have the Suitelet do that then?
b
that is my likely next step is to have it default, but honestly i got curious
so that's what led me further down this rabbit hole than i probably should have spent time on 🙂
k
Can you replicate issue this in the user interface?
b
i also wanted to figure it out in case our location logic gets more complex than just defaulting to one location. but by that point i might just have to script it anyways.
k
That is strange - one thing I've done to help in the past with workflows and dependent fields (location is dependent on subsidiary if you are one world) - is to put the value into a workflow field and then to put it into the standard field from the workflow field
but that's always been to do it in the user interface.
b
oh that might be worth considering
k
So, never tried it with a suitelet. and it's really odd that it says "hey I set this" but you open it later and it's not set.
b
as for replicating in UI, not sure. this was brought to light this way and we've trained our users to always set the location, or at least they should, so it'd be hard to find.
yeah, it's super bizarre in my mind.
we are on one world, but at this point we don't really need to be. i think someone over complicated the implementation. we really only use one subsidiary
i think i'll try the WF action field to capture value and then use that to try setting the line level and see if that fixes anything. if not, we'll just default to using the integration to set default location for now.
it stumped our NS ACS partners but we haven't paid them to investigate it further, not really worth it at this time.
a
i believe i ran into this before and needed to directly set line.location.id or something stupid like that
b
that would be dumb! but I'll keep that in mind. I'm running with the WF state field to capture body location and using that to set line level. however, i'm capturing the id in the WF state field, hoping that that does a better job than just text.
a
it's been a while since i ran into this honestly and i don't have access to that account anymore to check
but it was pretty maddening as i recall and wound up being something dump
b
bummer, but thanks for the feedback.
a
might have even been another workflow conflicting with it...worth a check
b
yeah, i'm continually disappointed with how often that happens in NS.
yeah, i looked for other WFs and scripts. we only have like 30 WFs and I don't recall any from my review that touched line level info. the scripts on the other hand, we have a lot of, but it's an intermittment problem, so hard to debug
quick update, the WF field didn't fix it. an order just came through with the same issue.
a
dang