Access to previous and next records

Can you clarify - are you trying to add the ability to go to the previous / next record from a certain record's Summary View page?  If so, I think it's doable but I don't think any button will do it - you'd need to use a link.

Is the fv!identifier the DB primary key?  If so, in your record interface you could simply query single entries from the DB where the primary key is one less than the current (for previous) and one greater (for next), and simply use those queried values in your a!recordLink calls on the interface.

Hi, Mike, thanks for the reply.

I would be happy to do this from a summary view if possible. I misspoke when I said 'buttons'; I had intended to use a dynamic link.

The fv!identifier is the unique DB primary key, but these are autogenerated when the records are created, and as records get deleted that identifier is no longer guaranteed to be one number away from its fellows. As an example:

ID: 1
Name: Bob

ID: 2
Name: Helen

ID: 3
Name: Chris

If Helen is deleted, the IDs are still unique, but when viewing Bob's record, adding 1 to the identifier will not get me to the next (Chris). What I was hoping for is access to the actual index of the array that Appian is creating when I run a filtered query on my records. So I may get:

ID: 1
Name: Bob

ID: 8
Name: Edward

ID: 10
Name: Jane

But regardless of those ID numbers, within the array the index numbers are what I wish to reference to move around. They'll always be contiguous and specific to the query to ensure my clients only have to page through the selected records.

EDIT: Ah! I think I've located what I needed with the WHERECONTAINS function - if I can pass in the fv!identifier as the value it should be able to return to me the array index. Thanks for your attention, all. I think I'm all set.

I do recommend against hard-deleting database entries (based on hard-earned personal experience), and instead using a flag i.e. "IS_DELETED" and/or "IS_ACTIVE" columns (having essentially equivalent yet opposite meanings). 

But regardless, you wouldn't simply say "current ID is 8, so the next one will be 8 + 1", but instead you'd run a standard query entity, batch size 1, where pk_id > local!myCurrentId, ascending = true (for getting the next one) and false (for getting the previous one).  This should work in any case and regardless of row deletions (i.e. if your current ID is 8, and you run the query i'm describing, it will grab the row with primary key of 10 since 9 has been deleted).

I do recommend against hard-deleting database entries (based on hard-earned personal experience), and instead using a flag i.e. "IS_DELETED" and/or "IS_ACTIVE" columns (having essentially equivalent yet opposite meanings). 

But regardless, you wouldn't simply say "current ID is 8, so the next one will be 8 + 1", but instead you'd run a standard query entity, batch size 1, where pk_id > local!myCurrentId, ascending = true (for getting the next one) and false (for getting the previous one).  This should work in any case and regardless of row deletions (i.e. if your current ID is 8, and you run the query i'm describing, it will grab the row with primary key of 10 since 9 has been deleted).

Thank you for this alternative! I will take your advice re: deleting (or NOT deleting) database entries to heart, and this query-based workaround to ensure we get the next viable entry will be my fallback if I can't wrangle the indexes into line. When running my initial record query should I take care to sort by ID to get an accurate result?