I am creating a tempo report using data from external database.

@jaishankarj Here goes a few ways of doing so as per my knowledge. One, you could create a rule in Appian that returns you text status based on status of type integer and apply this rule in the interface wherever you are surfacing the status. Documentation at https://forum.appian.com/suite/help/7.10/SAIL_Recipes.html#Format_Data_from_a_Record_in_a_Grid is a good example for this. Two, create a formatted cdt with the same structure as original but maintain an extra column called status_txt and populate this cdt with same as original and additionally populate status_txt with a rule such as discussed in the Approach - 1 . And thereafter you could make use of this new cdt as it contains status of type text. Three, make use of a database view and add the status of type text in the view and populate it as per the data hold by status column.

Approach - 1 will help you if it is just for display purpose. I would prefer this approach when I don't need to depend on display data anywhere in my implementation. Approach - 2/ Approach - 3 should be opted for, when we are depending on display data. For instance if we want to sort the data in grid, if we just apply a formatted rule and change the data in grid, sorting still works on the underlying data bot not on the displayed data and the results won't be as expected.

Approach - 2 and Approach - 3 are mostly the same and these will help you when you are using the data for export to excel implementations or sorting in grid etc. The only difference between Approach - 2 and Approach - 3 is that Approach - 2 adds an additional overhead in terms of execution of SAIL interface as the amount of time spent by rule in formatting the data and populating the cdt is proportional to size of the actual cdt. Approach - 3 works for you perfectly in any case and has upper hand over Approach - 2 but it needs creation of an additional database object. I would opt for Approach - 3 for most of the times over Approach - 2. Approach - 1 will help you just for display purposes and you need to remember that it won't be useful in the sorting in paging grid/ export to excel implementations and further these kind of rules adds additional overhead to SAIL execution times.

I hope the above explanation throws light on few available approaches and let's see if any other practitioner comes up with new suggestions.

Create a rule that takes in your integer value and returns your text alternative. Then simply use the apply() looping function on the data attribute of your grid text field:
apply(rule!myStatusConv, index(local!datasubset.data, "statusField", {})

In that formatting rule you can use the function displayvalue().

Formatting on the fly might not be a great idea always from my perspective especially if the formatter rule queries the database or if the column is intended to be used in sorting.

Agreed but sorting on a field with such low cardinality is relatively pointless, best to provide a filter field outside of the results grid.

Another idea: One could create a view on this table in the database and handle the alternative text there.

I recommend DB view approach. Let the DB work for you, you will have better performance than other approachs.

Correct, I too believe that DB approach is a ideal one, as said by me already earlier.

Thanks for the views. I created a view and then used the same in order to display the data in PIE Chart on Tempo.