Can you change the Tempo tabs?

Unfortunately what you describe is not possible now. I'm sure there are creative workarounds that leverage embedded SAIL and Appian Sites that can provide a different end user experience with Appian.

1. The Tempo page tabs cannot be customized but you can decide what tab is more applicable to your most common use case and make it the start page for all your users forum.appian.com/.../Appian_Administration_Console.html

You can also use this feature to set the start page to be a particular report for one group of people and another type of report for other group.

2. Another interesting feature in Appian is sites forum.appian.com/.../Sites.html you should also take a look at it. You might want to take advantage of this for a particular set of users

3. In the old Apps Portal pages used to be an entry point for both reports and process launching. This is now split in three with more features:

Records forum.appian.com/.../Records.html
Reports forum.appian.com/.../Tempo_Reports.html
Actions forum.appian.com/.../Process_Modeling_Tutorial.html

4. Your applications dropdown can now be the Actions tab for example because it categorizes them through applications on the left hand side menu

5. Most of the times you see users not very keen to adopt Tempo is because they are not 100% aware of all the powerful and easy to use features the modern UI offers. A good way to share this information with them is the Appian Quick Reference Guide from the documentation.

I suggest you take a look at it to get to know more the capabilities of the modern UI forum.appian.com/.../appian_quick_reference_guide.pdf

That is a good information Edu. Thanks !

Thanks Eduardo. That will help when we get to 7.11. We're not there yet. I would still like to create custom tempo pages though.

Also as an option, we created an 'Applications' record (entity-backed) which lists out applications and details to end users, to help assist with our conversion from Portal to Tempo. Metadata is stored for each application and used in facets, so filtering can be performed via search or department facets. Additionally, custom summary pages can be linked depending on which application record is being viewed, and application start links can be configured as Related Actions. With this layout we also store pm!id, pm!name, etc, to the DB which is very helpful for admin tools. This also allows you to post events related to the process model action in the news feed. We're just beginning our Tempo conversion, but this looks promising - figured it was worth a mention.

Applications record will *definitely* help with conversions from Portal. Great. Do you know which version it will be in? I would still like to create custom tempo pages though. ;-)

We are Appian customers and I created this myself, I'm unaware if there are any plans to implement something similar in the base product. For our custom pages, we are creating SAIL dashboards for each application. Then in the Record definition, we have our main Summary view definition call a rule that decides what page to display. For instance, the summary view of the Applications Record calls a rule which says:

if(rf!processModelName="HR Onboarding",rule!HrOnboardingHomePage(),
if(rf!processModelName="Finance App",rule!FinanceAppHomePage(),..
)

Then in HrHomePage() and FinanceHomePage() you can build out whatever should show as the Summary view page for that application record - and you have access to any data stored in the DB for the record entity using rf!. This allows you to link directly to that record from external sources (which we do), showing the custom page to the user when they land at that application via the external link or when they browse there from the Records interface. We implement this dynamic page loading in other views on the Applications Record as well, such as 'Reports', which looks at rf!processModelName and decides which report rule to show. Inside each report rule you can create a dynamic interface (via buttons or links) which loads one to many different reports specific to that application, which can also display or hide based on group memberships.

Similarly, you can expose Related Actions as the process model start event by configuring the visibility setting based on processModelName - if you want all functionality for users in one place (Reports, Actions, Home Page, etc). In the attached example, the "Software Install Request" related action is only shown when users are viewing the Software Install Request record item under "BPM Applications". The Post Process Model Event (which ties to the Application Record for News) and Manage FAQ (we also have a FAQ view custom to each application) are only shown for system administrators.

As an example on the different views, attached is what we are using currently (note we just started our migration). To use the Summary view as the example, I'll paste the rule!AM_Summary() code below. Note this is configured for one application, to have a custom page via rule!SIR_Home(), the other applications show rule!AM_defaultSummary() - which is a default page for those not yet configured. We also use a rule above the default page call, rule!AM_eventSchedulerDisplay(), which displays on every home page in this setup, when applicable. This is my solution for shared channels in portal which display across multiple pages. This rule takes the process model name and determines if there are any outages configured (via a separate custom tool) for that specific process model (mostly DB outages affecting one to many models, specific in the Event Scheduler application), returning blank {} for no outages or a paging grid with details if there are any outages scheduled that users should be aware of.

rule!AM_Summary():

= a!dashboardLayout(
firstColumnContents: {

/* Dynamic outage information */
rule!AM_eventSchedulerDisplay(rf!fldProcessModelName),
          
if(
rf!fldProcessModelName = "Software Install Request",
rule!SIR_Home(), /* Software Install Request Home Page */
rule!AM_defaultSummary() /* Default Summary Page */
)
},
secondColumnContents: {}
)