What are the most missing features in Appian that you are looking for?

Certified Senior Developer

I really like how Appian is evolving over the last coupe of years since i've stared using it. It is good to see regular release with new feature but there are a few that I'm really missing in Appian and could be game changer.

At the same time i would like you community what you are looking for to be added to Appian?

My most missing features:

1. More flexible filtering options for Grid. I would like to filter by any column in place having only values that are available if filter is added on other column. It should work similar how you can do it in Excel or in most tables on the web with simple JS dll. 

2. More control over Grid appearance. It would be good to be able to decrease the font size, spacing, padding and margin to make table more compact. It also would be good to prevent word wrapping and have more control over column width if text is long.

3. Possibility to write expressions as Java/Python code within Appian if there is such need.

4. Dedicated component for navigation sidebar/breadcrumb navigation

5. Possibility to upload files from shared directories

6. More control over Export to Excel for the record list

  Discussion posts and replies are publicly visible

Parents
  • 0
    Certified Lead Developer
    More flexible filtering options for Grid.

    Most of the things you list here are possible when you manually create your own filters on-form, FWIW.

    It would be good to be able to decrease the font size, spacing, padding and margin

    Decreasing font size is pretty straightforward by using Rich Text component and simply setting font size to small.  Cell padding is already reduced (to a certain extent) by choosing "dense" spacing for a grid.

    Possibility to write expressions as Java/Python

    Interesting, though I'm not really sure what this buys or how it would work.

    Dedicated component for navigation sidebar/breadcrumb

    The nice thing about being able to make your own custom components is you can customize it for yourself much more than any generalized OOB component would be able to accomplish.

    Possibility to upload files from shared directories

    I'm not sure what this means - do you mean on some automated basis, without the user having to upload on-form?  I believe there are plug-ins that can already help with this, but I haven't messed with them.

    More control over Export to Excel for the record list

    Agreed - and by "more control" you really mean "any control".

    FWIW, I have my own list of feature request / enhancement items.  Several of them exist as posts and/or comments here, i.e. if you search "[Feature Request]".

  • 0
    Certified Senior Developer
    in reply to Mike Schmitt

    Mike thanks for replay comments and links.

    To the above list i would like to add nother points:

    1. Error handing in process models - something simillary to try... catch that you may know from different programming languages. 

    2. Generic logging approach - setup logging for entire app and then use it whenever you want - something similar to C# Log4Net

    3. Multiple test case scenarios for UI - if you have UI with multiple ri then it would be good to be able to create multiple test scenarios and easily switch between them to validate if your logic still works.

    4. Possibility to test UI on DEV environment as different user. Quite risky but useful if you have different privileges' level or need to check maker/checker functionality as a single user.

  • 0
    Certified Lead Developer
    in reply to Furman
    create multiple test scenarios

    I really like this one.  I feel like this is a victim of different evolutionary paths between interfaces and expression rules - expression rules kinda "accidentally" got a way to store different default values (though it's a bit more of a pain to load one of them), whereas interfaces have a really easy way to store and load only one set of default values.

    test UI on DEV environment as different user

    Yeah - my usual approach is to declare a local variable early in an interface, i.e. "local!currentUser", which by default is based on the rule loggedinuser(), but which I can set to a different username to test other username-based form rendering approaches (group membership, etc).  But some things simply aren't testable just by passing a different username (folder security, rule security, function security), so it would be neat to have a "test as username" function for designers with the appropriate level of security.  I suppose it might just be too complex to figure out how to prevent someone from potentially abusing that.

Reply
  • 0
    Certified Lead Developer
    in reply to Furman
    create multiple test scenarios

    I really like this one.  I feel like this is a victim of different evolutionary paths between interfaces and expression rules - expression rules kinda "accidentally" got a way to store different default values (though it's a bit more of a pain to load one of them), whereas interfaces have a really easy way to store and load only one set of default values.

    test UI on DEV environment as different user

    Yeah - my usual approach is to declare a local variable early in an interface, i.e. "local!currentUser", which by default is based on the rule loggedinuser(), but which I can set to a different username to test other username-based form rendering approaches (group membership, etc).  But some things simply aren't testable just by passing a different username (folder security, rule security, function security), so it would be neat to have a "test as username" function for designers with the appropriate level of security.  I suppose it might just be too complex to figure out how to prevent someone from potentially abusing that.

Children
No Data