Dynamics CRM 2013: Diving into the sales pipeline – Part 2
In my previous post of this series, we discussed some fundamental concepts of the sales pipeline and how Dynamics CRM handles the sales process. While considering the requirements of ACME (a fictitious company), we defined the stages of their sales pipeline, and started to outline the functional specification of the opportunity entity, including the elaboration of an opportunity probability matrix.
In this post we will discuss how to implement ACME’s sales pipeline through the creation of a business process flow.
Understanding business process flows
Business process flow (BPF) is a new type of process introduced in Dynamics CRM 2013, which supports the creation of systematic approaches for common business process tasks to ensure process consistency. For example, when dealing with a customer support case, we can ensure that all users handling cases will go through the same stages of identifying, researching and resolving a case. Moreover, we can also ensure that each stage contains the same steps, and we can make some of these mandatory in order for the user to move to the next stage.
BPFs are represented through a prominent visual process bar which reflects the process phases and its key steps, prompting users to follow those steps in accordance with the defined workflow. Not only Dynamics CRM 2013 comes with some out-of-the box business processes (like the default sales pipeline mentioned in the previous post of this series), but it also has some additional ready-to-use business process which can be installed by a system administrator under Settings, Data Management. However as mentioned above, we will be creating our own business process, which will help us better understand how they work, but not before looking into the default one from behind the scenes. So let’s start with that.
BPFs are located under Processes within Settings, along our dialogs, workflows and actions (another process type new to Dynamics CRM 2013, which is out of the scope of this series). There we can find the two out of the box sales processes mentioned before: Lead to Opportunity Sales Process and Opportunity Sales Process. Let’s first analyse how they work.
The first thing to understand about those default BPFs is that they are completely independent from each other. Each BPF is bound to a primary entity, and is triggered only by such primary entity, even though it can span across other related entities. Let’s further compare these two, starting with the Lead to Opportunity Sales Process, which is bound to the Lead entity as its primary entity.
As we can notice from the first image above, the Lead entity only covers the Qualify stage of the BPF. From the second image we can see that the Opportunity entity covers all subsequent stages after the Qualify stage, these being Develop, Propose and Close.
In practical terms, this means that within this BPF, a lead record will always be under the Qualify stage. Once the Lead is qualified, the Opportunity record that is automatically created will move to the next stage in the same BPF, which is the Develop stage.
An important note on Lead qualification In Dynamics CRM 2013: In Dynamics CRM 2013, the process of qualifying a lead will always result in an opportunity record. It doesn’t matter whether a BPF that starts with the Lead entity includes the Opportunity entity (or any other entity for that matter). For better or worse, this process is built-in into the system and is completely independent from any BPF. For more information about the lead qualification process in Dynamics CRM 2013, please read my post entitled Lead Entity Changes in Dynamics CRM 2013.
Therefore, besides lead records the Lead to Opportunity Sales Process could only apply to opportunities that originated from leads. On the other hand, the Opportunity Sales Process could only apply to opportunities and not to leads.
Now let’s look at the stages of the Opportunity Sales Process, which is bound to the Opportunity entity as its primary entity.
As you can see from the image above, this BPF only includes the Opportunity entity. Being the default BPF for the Opportunity entity, when an opportunity record is directly created (i.e.: which haven’t originated from a lead) this is the BPF that will be assigned to the opportunity record.
Let’s now consider a Dynamics CRM 2013 implementation that has been using both these default BPFs. If we look into the opportunity records, we will see that they will all be assigned to the Lead to Opportunity Sales Process BPF if they have been originated form a lead, or to the Opportunity Sales Process BPF if they haven’t been originated from a lead.
Before we move on to the next topic of creating our own BPF, let’s have a look into a hidden component which is paramount for the customisation of BPFs: The Stage Category option set.
The Stage Category option set
If we take another look into the BPF images above, we will notice a column named Stage Category. The possible values for this column come from the Stage Category global option set. From this column we pick up the macro category of that our stage maps to. So if we have different processes, we can make sure their processes map to the same ‘holistic’ stages. As a simply analogy, suppose we have a different sales process for apples and oranges. The idea here is that we map the stages of both processes to overall stage categories for fruits. In fact, it is the value of the Stage Category column that shows in the sales pipeline funnel chart; not the value in the Stage Name column.
Customising this option set is important if you want to change the default category stage names, or if you want to add or remove available stages. However there are some guidelines that must be considered before we start customising it.
The first thing to consider is the label of the options. There is no need to prefix them with an ordinal value such as 1-Qualify, 2-Develop, etc. As a record moves through the BPF, Dynamics CRM automatically updates the Opportunity text field Pipeline Phase (stepname) with the current category stage name, and the prefix is added automatically.
The prefix value is taken from the order of the options in the global option set. For example, if The stage Develop is the fourth option in the option set, Dynamics CRM will append the number 4 in front of the category stage name.
Another point is the fact that the value of the options is ignored by BPFs. Whether the first option in the Stage Category has a value of 0, 1, 2,112 or 10,087 is completely irrelevant. The system only cares for their order within the list of available options. This can be a problem if you start moving options around, or add your own options in front of options that will be used by the sales pipeline. Even though you might have your BPF stages properly ordered as Qualify, Develop, Propose and Close, you could end up with your stages being out of order and incorrectly numbered in the sales pipeline funnel. The next screenshot is a good example of the mess we can get into if we fidget back and forth with the stage categories.
In fact if we look at the default stages in the Stage Category option set, we will notice that right after the sales pipeline stages we have some additional stages named Identify, Research and Resolve. These are the stages for case resolution and since they don’t have anything to do with the sales pipeline, they are added after the sale pipeline stages. If those were to be placed before the sales pipeline stages, the Qualify stage would be the fourth option from top to bottom. This means that any new opportunity set on the Qualify stage would have the value 4-Qualify for the Pipeline Phase field. Develop would be set to 5-Develop rather than 2-Develop, and so forth. Since the enumeration of stages only applies to the sales pipeline, this is why they come first in the Stage Category option set. You don’t have to worry about ordinal values for processes for cases or any other entity.
Last but not least, since the pipeline funnel chart is based on the values of the Pipeline Phase field of the Opportunity entity, it would only show opportunity records. Leads will never show on the pipeline chart, and they are not supposed to.
So without further ado, let’s move on to the creation of our new sales process, starting with its stage categories.
Adding our custom stage categories
So the first thing to do is to add our stage categories to the Stage Category option set. For that we must go under Settings, Customisations and choose the option Customize the System. On the Solution: Default Solution window that appears, click on Option Sets at the left-hand side, then double-click on Stage Category (processstage_category).
At the Stage Category option set customisation window, let’s add the following options before all other options in the following order, from top to bottom: Suspect, Prospect, Proposal, Negotiation and Deal.
Remember that the value of the options aren’t important, but their order is. This is why they must be at the very top of the options. If the Suspect stage were to to be fifth from the top down, then it would be enumerated as 5-Deal in the sales pipeline funnel chart. Since we added our stage categories, you might want to delete the out of the box ones, or just leave them there. Either way, trying to use them in a BPF will result with a mix of stages and senseless enumerations in the sales pipeline funnel.
After adding the options, click on Save, then Publish to commit the changes. After the publishing is complete, you may close the Stage Category option set customisation window.
Now that we have our stage categories, we can move on to create our BPF.
Creating our business process flow
Back at the Solution: Default Solution window (you should still have it open), click on Processes at the left-hand side. Now click on New to bring up the New Process creation window. Create a new BPF with the following values:
Process name: ACME's Lead to Opportunity Sales Process
Entity: Lead
Category: Business Process Flow
Click on OK to confirm your settings and load the BPF design window.
On the BPF design window, you can see that a default stage named NEW STAGE is created without a category. Click on this default label for the stage and type Suspect, then select Suspect as the stage category. It is very important that we specify a stage category, as failing to do so will result in blank entries showing in our sales pipeline funnel chart.
The next step in adding a stage is to add the steps that comprise such step. In other words, we must specify the fields that fall into the given step. If we specify a field within a stage as required, users will not be able to advance beyond that stage unless the required fields contain data.
Automating BPFs: It is important to point out here that the built-in BPF editor doesn’t allow for us to specify an automated flow, where records will move automatically through the process stages based on conditionals. This is a manual process by default, and any automation must be achieved through development.
For the Suspect stage, we got the same fields as Develop stage of the default BPF. Refer to the screenshot below to define the steps of this stage:
Now we need to add the remaining stages, which are within the scope of the Opportunity entity. Click on the +/- Options button right under Included Opportunities to display the ADD ENTITY drop-down, which shows all available entities that have a relationship with the previous entity in the BPF. Select the option Opportunity (Originating Lead). This will add the Opportunity entity as the next entity within our BPF, and it will be linked to the Lead entity by the relationship provided by the Originating Lead lookup field.
After the Opportunity entity has been added to the BPF, we need to add its stages and their respective steps. Make sure that OPPORTUNITY is highlighted within the BPF editor. Click on the NEW STAGE label for the default stage and type Prospect, then select Prospect as the stage category. Click on the + button next to Stages to add a new stage, name it Proposal and select Proposal as its stage category. Again click on the + button next to Stages to add a new stage, name it Negotiation and select Negotiation as its stage category. Now add the final stage, name it Deal and select Deal as its stage category.
Now let’s include the steps of our recently added stages. Again, I have based the stages on the ones included in the default BPF. Refer to the screenshot below to define the steps of these stages:
We’re almost done with this BPF. Now click on the Enable Security Roles button at the top of the BPF editor window to select the system roles this BPF applies to. Select Enable for everyone then click on OK. Back at the BPF editor window, click on the Order Process Flow button. This allow us to set the default order of preference for BPFs in the system. Use the green arrows to place “ACME’s Lead to Opportunity Sales Process” at the top of the list, then click on OK. Back once again at the BPF editor window, click on Save followed by Activate to make our new BPF available.
Our first BPF is now ready! Feel free to test it out, but remember that this BPF will only take place when a lead record is created. We now must create another BPF for when opportunity are created without an originating lead.
Our first BPF was created from scratch. For the next one, let’s make a copy of the default “Opportunity Sales Process” instead to speed things up. Let’s go back at the Process section of Dynamics CRM. Double-click on “Opportunity Sales Process” to open the BPF in the editor window. Once the window is open, click on the Save As button at the top to make a copy of the BPF. the process will be copied with the default name of “Opportunity Sales Process (Copy)”. Click on Expand ⌄ at the top-right of the editor window to expand the attributes pane of the BPF. Now we can click on the Process Name field to rename our BPF to ACME's Opportunity Sales Process. Click on Save to commit the change and the process will be renamed.
Now let’s change the default stages to reflect ACME’s. Since we are sticking with the default steps for this tutorial, this will save us some time. All we need to do is delete the first stage (Qualify), then change the names and their respective categories for the remaining stages to reflect ACME’s process. Refer to the screenshot below as a reference:
What happened to the first stage?
Some of you might be wondering why did we not include the Suspect stage in the Opportunity BPF. After all, if we compare it with the default BPFs of Dynamics CRM, the first stage (the Qualify stage) is included in both the Lead BPF and the Opportunity BPF. Well, here is where Microsoft and I will have to agree to disagree. In my view, that doesn’t make any sense from a business perspective. The Lead entity is supposed to be an stage (or a set of stages) within itself, so why duplicate the stage in the Opportunity entity? After all, creating an Opportunity directly means creating it for an existing customer (account or contact) and therefore it is not a lead — thus stage(s) for the lead shouldn’t apply. Not to say the mess this would create for our users’ sales pipeline, where part of their sales records in the qualify stage would appear in the sales pipeline funnel chart (i.e.: Opportunities in the qualify stage), and part wouldn’t (i.e.: the Lead records — since the pipeline funnel chart only shows opportunities).
If you plan to go down this route as well, bear in mind that since Suspect is the first entry in the Stage Category global option set the pipeline funnel chart will always start from the second stage (2-Prospect), never showing a first stage. This might look odd to some users as a stage with the ordinal value of 1 (first) will never be seen at the pipeline funnel. If you consider the Suspect stage to be the 0 (zero) stage and the Prospect stage to be the first stage, then you might want to move the Suspect category in the global option set to be the last one (i.e.: just after Deal). This way Prospect will be enumerated as the the first one (1-Prospect), and this wouldn’t affect the Suspect stage since it only applies to lead records; thus never showing in the sales pipeline.
Having said all that, this is my personal view and by all means you should feel free to add Suspect as the first stage of the Opportunity BPF if you wish to do so.
We’re almost there. Now click on the Enable Security Roles button at the top of the BPF editor window to select the system roles this BPF applies to. Select Enable for everyone then click on OK. Back at the BPF editor window, click on the Order Process Flow button. This allow us to set the default order of preference for BPFs in the system. Use the green arrows to place “ACME’s Opportunity Sales Process” at the top of the list, then click on OK. Back once again at the BPF editor window, click on Save followed by Activate to make our new BPF available.
That’s it! We now have two custom BPFs. One covers leads and their conversion to opportunities, while the other covers opportunities without an originating lead.
Coming up next: Customising the Opportunity entity
In my next post we will be discussing how to customise the Opportunity entity in order to support the requirements discussed so far. New to Dynamics CRM 2013, we will be using business rules, which is an alternative to JScripts.
Great article Pedro. Thanks for posting!
Nice walk through. You may be interested to know that there is a posted mechanism for changing the process through synchronous or asynchronous workflow processes here https://community.dynamics.com/crm/b/develop1/arc…
It also has a link to a free solution file to enable it.
Thank you for the tip, Charlie!
Great postings, look forward to Part 3, the earlier, the better 🙂
Hi Kevin,
Thank you for the kind words :). I reckon that part 3 will not happen before the Christmas, as I have an important assignment to deliver for the 23rd of December. But rest assured that IT WILL happen 🙂
EDIT: Expect it on the week of 27/Jan/2014.
Regards,
P.
Pedro, Great with some clarification of the new process!
Does this mean that when my customers upgrade I:
1) can't make stages change automatically using workflows?
2) can't take an upgraded online organisation's complete set of opportunities (its pipeline) and make it updated to the new logic? (I understand from CplCarrot above, you can make a developer fix it, but can this really be true?)
Thanks in advance for you answer.
Regards HKappel
Hi (hej) there HKappel,
Your solution would have to include some level of development, be it a custom workflow activity or an entire plug-in on its own.
The solution shared by CplCarrot relies on the creation of a custom workflow activity in Visual Studio, and a bunch of JScripts.
Regards,
Pedro
Interesting article and makes things clear. Somehow, I'm still confused about all other fields with stages or steps defined…
You have:
– Sales Stage (salesstage – refers to global option set opportunity_salesstage with values Qualify, Develop, Propose and Close);
– Process Code (salesstagecode – option set with only Default Value);
– Process Stage (stageid – unique identifier which refers to the stage defined in BPF);
– Step (stepid – defines the sequence of the stepname);
– Pipeline Phase (stepname – text field to store the value in the global option set Stage Category based on the sequence in this option set of the values);
I'm not quite sure why there are so much fields to store practically the same information. The fields Sales Stage and Process Code are confusing in the way they act or how they should be used when you're actually only using the Stage Category option set to fill in the Pipeline Phase (which is then filling in the Funnel chart).
Can you provide more information about the difference and corresponding behavior if you choose to use these? Or is this coming in part 3?
Regards,
Stijn
Hi there,
Sorry for the delay in answering, but I’ve been working on some aggressive deadlines. this is not a thorough answer, but it might help you get started. I plan to post more information about those in the future. Some fields I might discuss in this series as ‘the way it used to be’, but some are not relevant to this series. — at least not directly.
* Pipeline Phase – This field is the one used to store the text value of the pipeline phase, concatenated with the ordinal prefix. For example ‘1-Qualify’ being a concatenation of the stage category Qualify and its position in the list, which is the 1st one. This is described in detail in the above post.
* Process Code (salesstagecode) – This field is now a legacy field, and I wouldn’t worry about trying to customise it. Just leave it be. I did explain in the ‘Diving Into the Sales Pipeline’ series for Dynamics CRM 2011 how to leverage this field to implement a sales pipeline.
* Process Stage (stageid) and Step (stepid) – These fields are used by the BPF automatically and you shouldn’t really fiddle with them. In fact, every time you enable BPFs into an entity, the system will create a bunch of fields in order to support the BPF. Those fields are some of them.
* Sales Stage (salesstage) – This fiield was introduced with Polaris sales process and it doesn’t seem to work directly with the BPF in Dynamics CRM 2013. I will investigate it further and come back to you on this one.
Thanks for the answer. I was able to complete my BPFs and my funnels were filling nicely (with correct numbers), however, I exported my solution and imported it again in our live system which is now causing problems with the numbering of the Pipeline Phase. After data migration, all Opportunities were set to a Pipeline Phase with odd numbering. I only use 6 stage categories (the default ones are still there tough), So my numbering was 2- 3- 4- 5- 6-, but now in our live environment I have like 35- 36- 37- 38- 39- …
I then exported everything, changed these values in the field to the correct ones, imported the records and it was all good in my sales pipeline chart. But, now every new opportunity created by the users gets another number again like 16- instead of 2-.
Any thoughts?
Have you checked the Stage Category global option set? This is the first place I would like if I get some odd (odd as in 'weird') numbering in the pipeline phases.
I did, yesterday I partly solved it, but today it's not working anymore.
Now I have the right ordering in the global option set, but every opportunity that's now created or moves to next stage is not following the sequence; I have 6 categories set up and now a new opportunity is starting at 8-Identified instead of 2-Identified. If an opportunity moves to another phase, it's for example from 3-Review to 10-Approved (instead of 4-Approved).
The option set is in the correct order…
I am having this same issue. It happened when I imported a solution that was exported from another environment. I'm wondering if the solution messed up the numbering.
I am having this issue as well. Might have been caused by importing my solution from a dev environment. I have not changed the processstage_category option set at all….
I opened a support ticket with MS. I will update as soon as I have news.
I just finishing handling a massive MSc assignment so I shall have some time to breath until next week. I will have a look at this as well. Might ask for other CRM gurus for their opinion on the matter.
The support ticket has led to nothing, they say they have to research (it was a free ticket, you get what you pay for). I built a real-time workflow to convert the nonsense values to the correct values. I can affirm that I did multiple solution package passes between dev and prod. That is the only thing I think that could have confused the stagecategory / pipeline phase automation. I look forward to your feedback after you have had a chance to review.
Hi, I have investigated that case. ms does not calculate the number dynamically but stores it in DB, in "Display order" field of AttributePicklistValue table. These values will be calculated and stored when you edit the option set. when you import the solution however, the numbering gets wired. it seems to be a bug. the workaround is to change the positioning of some of entries in option set back and forth after solution import, then it recalculates and stores the values in db correctly. I'll give you update if I find more.
this workaround is only for unmanaged solutions though. do you also have problem after importing managed solutions?
Almir,
I managed to replicate this issue today. Clearly this is a bug, regardless of what Microsoft might say (after some bad experience at Microsoft Connect, I am anticipating — perhaps unfairly — some sort of "by design" remark). I think the workaround you proposed should suit most users, but not all. There might be a small set of users looking to have a managed solution that implements a custom sales pipeline; although I would wonder why!
I'm now using a workflow that's filling in the pipeline phase field with the process stage. I changed the stage names and put the correct number in front of it. This solves the issue for me, I hope MS comes with a solution themselves quickly.
Read all about my workaround here: https://crm2013experience.wordpress.com/2014/02/1…
(I linked to this blog as well)
Nice Posting Pedro,
Can u help me by providing some sample Business Scenarios of CRM Application Testing..
Am New To CRM Applications
Hi Satish,
What do you mean by business scenarios of CRM application testing? Not sure I follow you.
Do you want to know scenarios where a CRM system is useful?
Hi,
Yes I need scenarios where a CRM system Uses,
Could you please provide me some Common Complex Scenarios used in Microsoft Dynamics CRM
(or )
provide me some Common Complex Scenarios used in CRM Systems
I am not sure if you mean complexity around the business requirements or around the technical implementation. Here is an example of something I did once:
A organisation was looking to use Dynamics CRM as the central repository of structured data for the Sales and Marketing dept. However we do have customer information among other systems, mainly an IT Service Management System (HP's Peregrine). Accoun managers require to have some view of important support cases for their clients, such as case swhich are in danger of breaching the service level agreement (SLA). The business didn't feel like having to provide account managers with accounts to Peregrine for several reasons. Peregrine has been heavily configured for the support team and there is a lot of info which is complex and irrelevant to account managers. Also account managers would have to be constantly jumping between Peregrine and Dynamics CRM. What I did was a small integration between Peregrine and Dynamics CRM which would get only the critical open cases and replicate those in Dynamics CRM; and only with the relevant information. This replication happened incrementally every 12 hours.
Very informative post Pedro, thanks for sharing it. The sales process scenario discussed in the post is applicable to most of the organisations, However, Can you suggest any way to shorten the sales process ? especially when payment is already received and CRM is only used to reflect the following – order, invoice and payment. I'm not sure about the usage of opportunities, quote entities in above mentioned scenario.
Hi Shirish,
I never liked the use of Dynamics CRM for order, invoice and payment — at least not the use of those entities on their own, with Dynamics CRM being the central repository of such data. Reason being is that Dynamics CRM (or any other CRM for that matter) isn't a financial or ERP system. Simply put, I would never use Dynamics CRM solely for order, invoice and payment.
Hi Pedro,
Thanks for providing your input.
In the scenario specific to our organisation, we receive all the order and customer information along with the payment receipt details after customer buy the item from our website. In short CRM is currently being used to maintain the contact / account information and also for creating opportunity, quote / order / invoice and to allocate the payment to the invoice and posting the transaction to ERP (which handles order fulfillment and other processes).
Our process is not exactly the multi-step or iterative sales process and the creation of the quote to payment allocation to the invoice and posting to ERP can be done in few mins.
Now because our process is very consistent, predictable and straightforward, I'm wondering if we really need to use opportunity / quote / order,invoice and payment entities in "Transactional Type Sales Process" as they are not adding any value to the order processing in CRM at least in our case and get away with creation of order,invoice, payment to complete the sales order process.
I'll appreciate your insights on above.
If you receive all the order and customer information after the customer purchase items from your website, then I don't think you require the use of opportunity records. Lead and Opportunity records are useful for the hunting and farming of customers. In you case, if your are solely an e-commerce site (i.e: you don't have account managers and business developers going out and about generating leads and opportunities) then I certainly don't see the use at all for Opportunity.
What I would do is centralise all the financial and administration info in the ERP, and surface some of this information onto Dynamics CRM. You could still use Dynamics CRM for marketing purposes and some market analysis. But I see little to no use for the sales moule.
Thanks Pedro for taking time to provide your insight. I appreciate it.
You're welcome. You should look into tools such as SQL Server Data Tools (SSDT) or Inscribe (a bit pricy, though) for integrating data from your ERP into Dynamics CRM. If using SSDT there is a plug-in called Kingsway adapter that I recommend for performing scheduled data loads. Hope this helps!
Cheers,
P.
A really helpful post (even if I already have worked with BPF already), I learned some new things, thank you very much!
Thanks for the great article. I have one question if anyone can maybe help me to understand the following: How does the probability field affect the opportunity? If my products add to 100 000 and my probability is R50%, is the system not suppose to update the estimated revenue to 50 000?
Dear Christo,
That is a great question. The fact answer is: it depends on how you design the application. Some organisations do adopt this model, which is often called the 'weighted estimated profit'.
I have designed this in the past and is not difficult at all, particularly now with business rules and/or synchronous (real time) workflows. The question is: what field shall hold the weighted estimated profiled, and which field should hold the original value? Personally I would keep the original estimated value in the default field, and created a new one to have the weighted estimated value. Of course you would have to create new views and charts, and probably some new reports. But this is all part of the fun 🙂
I agree with you Pedro on the part where it doesn’t make sense to have a qualify stage on the Opportunity entity, In my opinion the qualify phase on the opportunity can though be justified because in some scenarios customers choose not to Work with the lead entity. They wish to manage leads as accounts where leads/prospects are managed through the Relationship type. Having that in mind the qualify phase make sense all of a sudden 😉
Great articel Pedro!
Hello Christo
You can create a business rule to make the "weighted" calculation on the opportunity. By default Microsoft CRM does not calculate the weighted revenue.
Hello,
great article.
I was wondering if anyone knew if there is a way to drill down more into the pipeline phase. For example an opportunity form will have the separate phases and within a phase there are several fields that you need to fill. Is there a way (possibly via advanced find) that you can find the opportunities and their relevant phases in the pipeline but also see what fields have been filled against that opportunity? This way we will be able to tell more accurately where the opportunity is within the stage.
Thanks
Hi Natasha,
If I understood correctly, you want to find out the stages in which an opportunity is at through the advanced find, and the relevant fields that have been for the specific stages, is that correct?
The first thing to tackle is the field that defines the stage in which your opportunity is at. If you followed the full tutorial series, we identified a bunch of fields that can help you with that. There is one particular field named Pipeline Phase (stepname) which is populated with the stage name prefixed by its ordinal position (e.g. "1-Prospect").
As for the fields have been filled against that opportunity, you should be able to create a view that contains the most important columns for opportunity records overall. However the challenge is when we have fields which are pertinent only at certain phases. For instance, we might have a date field with a deadline date for the submission of tender response which is only relevant to phase 3. For this reason, I would often add a custom view to list opportunities with relevant field for each phase. Hope that helps!