Starting different processes on condition from a site page

Hi everyone,

I'd like to optimize the use of the pages on my site (limited to 5). To do so I would like to use 1 page to start 2 different processes depending on the group you belong to (start process 1 if I am a member of group 1, start process 2 if I am a member of group 2, very basic). Both processes have a start form.

Since we can not apply a condition in the page parameters when calling a process, how could I reach my goal without an extra click for the user?

I've tried different solutions like : adding a "master process" with the condition and then call the process, or adding an interface and then call a different process on click but it seems impossible to do it automatically.

Thanks for your help!

Lionel

  Discussion posts and replies are publicly visible

  • I would do a page on the site pointing to the "mater process". The start form would then be two interfaces (in one interface with showwhen conditions) that would display one form or the other depending on the user groups.

    The submit button would store a Boolean that would indicate which sub-process shall be called depending on which group the user belongs to.

  • 0
    Certified Lead Developer

    I suggest you consider a "wider" approach here.  Manuel's solution would work, I expect, but in the long term, what happens if this needs to expand to let's say 3 or 4 different processes?

    I think you'd get a lot more flexibility by just ditching the "start page" approach, and instead aim at having a general SAIL form displayed on your site tab (this would be done by way of making the SAIL form a "report", even though it's not a report, but really that's just a silly naming convention mismatch).

    Anyway - on your SAIL form, you would do all the same logic up front -- evaluate which group a user is in.  Show some input fields that save their values into local variables.  These can easily vary depending on the user/group, which seems to fit your desired design.  Then show the user a link (using  a!startProcessLink()) to whichever process model you wish to launch for them, passing in as parameters any appropriate data, including of course anything they've entered on the form. 

    This, in essence, becomes your "start form", but without the need to stash everything inside a "master" process with hardcoded branching between a set number of choices for subprocess.  In this manner, you'd potentially be able to add further branches to your logic and launch many other processes as needed depending on your future needs.

  • 0
    Certified Lead Developer
    in reply to Mike Schmitt

    I think either solution really works.  It's not that much more a laborious chore to add another sub-process node to your "master process" as it is to add another possible destination to an a!startProcessLink or more conditions by which a new a!startProcessLink should appear.

    I think that Mike's idea is splendid, and really only contains one drawback.  You see, a!startProcessLink for whatever reason cannot be attached to an Appian button.  You could certainly attach it to an image of an Appian button, if you wished, but it would be a bit noticeable how the graphic behavior of the button did not quite match what the user normally expects.  You can use Rich Text, Icons, a Card Layout, Images, any number of other components, but not a button without taking Manuel's approach. 

    Really a tiny thing to separate the two, but there it is.  If you're OK with the loss of the use of a button, I think a!startProcessLink will prove the more manageable solution.  And depending on what Appian gives us next week, we may see the one limitation to Mike's suggestion removed.

  • 0
    Certified Lead Developer
    in reply to Dave Lewis

    Agreed - the inability to use a button to mimic *at least* the "start process link" functionality seems to be a bit of a functional underlap (just like how links other than submit link can't give a "confirmation pop-up", though that's a different thread entirely as you're probably aware).

    Peronally though, I'm not too plussed about the inability to use a button here - as you mentioned it would be possible to use a card layout, and these can be used to create a reasonable "fake button", and of course Rich Text provides a lot of alternative possibilities.  I see it as worth the trade-off. 

    And yes, I too am crossing my fingers that they might finally start addressing some of these seemingly "low hanging fruit" functional underlaps in 20.1 -- maybe?

  • Thanks for all your precious feedbacks! Probably the most important thing is to change my mind (and my habits) about the use of a process and a start form.

    I'll for sure consider different elements of your answers since my current solution looks like this:

    • Process 1: a chain of a!startProcessLink() with cards as buttons to navigate between interfaces an complete the global process (1. Choose a category of event to declare > 2. Choose a specific kind of event > 3. Choose a very specific kind of event > 4. Declare the event)
    • Process 2: a basic form with a submit button (complete all datas about the event and declare on button click).

    Anyway I'll wait and cross my fingers too for the possibility to use a a!startProcessLink() with a button.

    Thanks a lot.

    Lionel