What applications to create on a new project

My recommendation would be to find a relatively simple paper process that you think you could optimize using Appian.

For instance, one bank client I was working for had a process whereby a lending specialist would fill out an excel sheet containing the details of a loan product a prospective customer might be interested in.  A member of another role at the bank would receive a paper copy of that excel and type the values into another system by hand.  Eliminating that swivel-chair by doing it automatically would be a huge cost savings to the bank and not be terribly complicated to build in Appian.

What would you need?  You'd need a SAIL version of the form; either a way to print out the data, a webservice or the like to send it directly to the other system, or both; a process model to run it all; and possibly you might want to store these in a database for auditing.  If you are going the database route, you'd need at least one CDT to match the table you're going to be writing to.

You might have a paper process, or a legacy system, for requesting time off.  That would need a SAIL form, a process model, and tasks assigned to various roles.  You'd have to manage groups, permissions, and would probably want to add swimlanes to your process models.  You might want to persist requests in the database, and possibly generate reports.

The project I'm working on now, the client hated Remedy, so a couple of developers were tasked with building an Incident Reporting solution in Appian for tracking tech support tickets.  That only took about a month for 2 developers to fully replace Remedy with a custom built Appian solution.

Ideally your first project would follow one central flow and encompass one and only one overarching process / product.  It only requests time off.  It only makes initial loan requests (no other kinds of requests).  It only carries tech support tickets through their lifecycle; it's not a code repository, it's not a diff tool, it's not an IDE, it's not a project planning tool, it's not a collaboration bulletin board, it's not a knowledge sharing platform, it's not a SCRUM meeting organizer, it's not a release planner, at least not yet; it's ONLY a support ticket tool.

But whatever process it does or product it creates, it should be big enough that it utilizes essentially every kind of Appian object there is.  You would almost be remiss if it didn't have process models, subprocesses, datastores, cdts, records, groups, actions, related actions, loads of expression rules, maybe document generation, and maybe a report or two.

And don't make it just to make it.  Make something that will get used and be much better than what it replaces.  Get your buy in.  Give the business ROI early, and let them see early that they made a good choice picking Appian.  That will secure you to tackle a much bigger project that does lots of things next.

My recommendation would be to find a relatively simple paper process that you think you could optimize using Appian.

For instance, one bank client I was working for had a process whereby a lending specialist would fill out an excel sheet containing the details of a loan product a prospective customer might be interested in.  A member of another role at the bank would receive a paper copy of that excel and type the values into another system by hand.  Eliminating that swivel-chair by doing it automatically would be a huge cost savings to the bank and not be terribly complicated to build in Appian.

What would you need?  You'd need a SAIL version of the form; either a way to print out the data, a webservice or the like to send it directly to the other system, or both; a process model to run it all; and possibly you might want to store these in a database for auditing.  If you are going the database route, you'd need at least one CDT to match the table you're going to be writing to.

You might have a paper process, or a legacy system, for requesting time off.  That would need a SAIL form, a process model, and tasks assigned to various roles.  You'd have to manage groups, permissions, and would probably want to add swimlanes to your process models.  You might want to persist requests in the database, and possibly generate reports.

The project I'm working on now, the client hated Remedy, so a couple of developers were tasked with building an Incident Reporting solution in Appian for tracking tech support tickets.  That only took about a month for 2 developers to fully replace Remedy with a custom built Appian solution.

Ideally your first project would follow one central flow and encompass one and only one overarching process / product.  It only requests time off.  It only makes initial loan requests (no other kinds of requests).  It only carries tech support tickets through their lifecycle; it's not a code repository, it's not a diff tool, it's not an IDE, it's not a project planning tool, it's not a collaboration bulletin board, it's not a knowledge sharing platform, it's not a SCRUM meeting organizer, it's not a release planner, at least not yet; it's ONLY a support ticket tool.

But whatever process it does or product it creates, it should be big enough that it utilizes essentially every kind of Appian object there is.  You would almost be remiss if it didn't have process models, subprocesses, datastores, cdts, records, groups, actions, related actions, loads of expression rules, maybe document generation, and maybe a report or two.

And don't make it just to make it.  Make something that will get used and be much better than what it replaces.  Get your buy in.  Give the business ROI early, and let them see early that they made a good choice picking Appian.  That will secure you to tackle a much bigger project that does lots of things next.