First the most important question (if it has already been asked, I have overlooked it): How much time does this query currently take, and how fast do you need it to be?

The actual execution plan shows all actual rowcounts to be zero, even when estimates are in the thousands. This means (a) that either something is very wrong with the estimates or you did something very weird to get this plan; and (b) that the procedure probably ran very fast.

Could you also run it again, with the SET STATISTICS IO option enabled, and share the results of that?

Based on the estimated cost percentages, I agree with Chris' suggestion that adding ActivityDescription as an included column in the index **MIGHT** make the querry faster. But it might also affect performance of other queries running on your system, for better or for worse, so do run a full test in your QA database.

Various tables and indexes in the plan are scanned. Whether or not that is a problem is hard to tell without knowing how much data is in the tables.

Also, your table-valued function: it is written as an inline function, which is great. (Well done!). But its results are not deterministic: it has a TOP 1 without ORDER BY, which is the SQL Server equivalent of "just pick any random row that meets the criteria".