While this approach will work, it looks like you're creating a highly sparse cube structure. (This is often a a marker, for using BI technologies for othger purposes.)

From what I can see, you would be as far ahead simply designing a report from your operational data store, rather than trying to model this into a dimensional form. Some general quidelines that I've used on dimensional modelling:

- The dimension should be fully specified, without regard to other dimensions (or fact tables for that matter).

- Dimension values should be reusable via the intersection of the fact tables to other dimensions. For example, it should be a valid construct, where both customer A and customer B point to the same application. (I suspect that's not true in this case.)

- Ideally, fact values have some aggregation associated with them. BI is used to quickly identify trends, do rollups, etc.

Based on the comments from your original post, I'd expect the following:

Customer Dimension - track all chars of the customer

Time dimension - This is likely the "date sold", or when it was initiated.

Task Type dimension - type, category, etc.

Product dimension - details on the various financial products

The "data dimension" represents the application, and it's various stages:

Measures:

Time executing task

Application ID (rollup a distinct count of the application IDs)

Start date (rollup the minimum date)

End Date (rollup the maximum date)

Operator (rollup a distinct count of the operators)

Note: if the same task can occur multiple times for the same application, then you'll need to add a second time dimension.

I hope this helps.