Skip to main content

Hello Nintex Community,

I need a little help with some logic on one of the Sharepoint Nintex Forms. I've created an approval process that gets sent from participant to participant to either someone's emails(Participant1, 2, 3, etc - PeoplePicker field) or a team's email bin(TeamMailbox1, 2, 3, etc - List Lookup field) with a maximum of 10. Once the participants open the form they have two choices.

 

P5choice, ParticipantsFull (screenshot below)

- P5choice: Values (Next, Previous, Delegate, Reject, OPI)

- ParticipantsFull: Values (Next, Reject)

 

I want P5choice to be visible as long as Participant10 is empty and TeamMailbox10 is empty, this way MORE participants can be added.

I want P5choice to stay visible if participant 10 wasn't reached until after they answered(during participants 6, 7, 8, 9, etc.)

 

I want ParticipantsFull to be visible only if ALL 10 participant slots are taken up, this way NO MORE participants can be added. 

I'm pretty sure the logic for Hiding ParticipantFull is good

( isNullOrEmpty(Participant10) && isNullOrEmpty(PositionalMailbox10) ) || !isNullOrEmpty(p8choice)

 

I'm struggling to try to come up with the logic for P5choice. If anyone could give me a little bit of guidance I would greatly appreciate it. 

 

I tried to give as much information about the form as I could. If anything was missed or needs to be clarified I can provide more screenshots or information if needed.

 

Thank you for taking the time to look over my post.

 

 

 

sorry a little typo in there, I meant to say the logic for hiding ParticipantFull on Participant5's section is



( isNullOrEmpty(Participant10) && isNullOrEmpty(PositionalMailbox10) ) || !isNullOrEmpty(p5choice)



 



 

It looks like the controls you want to hide / show based off of the logic of whether or not you have reached your max capacity for participants, share the same essential options (both have "Next" and "Reject"). Would it be easier to just keep the P5choice control and **validate** the selection based off of whatever logic instead of trying to show / hide controls that share functionality?



 



 example




(Passes Validation. Participant Count = 4, Choice Selection = "Previous") 
Participants: John, Mary, Larry, Dave

Choices: [] Next [] Previous

  • Delegate [] Reject [] OPI


    (Fails Validation. Participant count = 10, Choice selection = "Previous")
    Participants: John, Mary, Larry, Dave, Danny, Jimmy, Shawn, Dawn, David, Mike

    Choices: [] Next [] Previous
  • Delegate [] Reject [] OPI

    -----
    This way if someone picked an invalid selection (because you reached the max amount of participants) then they would get an error message and could correct as needed.



     



    Other thoughts: It might be helpful for you to rename your controls to something less confusing and centered around their *function* as opposed to a description of some trait. You talk about Participant10 and TeamMailbox10, but it's impossible to tell what you're talking about just via a screenshot that doesn't have any names attached to the controls.

    Though it isn't mandatory, having things named in a clear way is helpful in conceptualizing how they will work together, and make it easier for anyone else who might see them / work on them to understand what they are for, at a glance. By keeping the "properties" of the controls out of the Control Names, you also don't paint yourself into a corner in the event that a Control Changes and maintain a consistency. 

    • Reply


    View our Community Site Map

    Nintex Community Sitemap
    Terms & ConditionsCookie settings