MAXROW() can ignore rows you don’t want considered. So long as the rows of the table contain sufficient information to determine which rows are relevant to the user, no slice should be needed and MAXROW() should be sufficient.
There are two common approaches:
Create a virtual column with an app formula that uses MAXROW() to find the desired row, then dereference that column to get access to its JobNr column value. For instance, if this virtual column is named MyColumn, you could dereference it with
[MyColumn].[JobNr] to get the JobNr column value from the row it references. This approach is especially good if you have use for other column values from the same row.
Alternatively, combine MAXROW() and LOOKUP() to get the value in a single operation. This is an advanced approach I wouldn’t recommend in your case.
As noted above, you can dereference the Ref value found in the virtual column. Simply make the initial value expression:
Yes, yes, yes, no. Whenever a new row is added, the user must interact with the row, even if just to hit Save. They’d also have the opportunity to click Cancel, which would likely be undesirable.