Customer Engagement & Dynamics CRM Forum

I have finally developed an SDL process for our org and my last task is to determine a naming convention for our solutions. We'll be going with unmanaged solutions in all envs because of our size and small team (aka, me).

My question is, how do you name your solutions? So far we're thinking "SOL-CE####-INT-DESC" where we ID it as a solution for our DB sake, then note that it's a CE solution with a sequential number, then the initials of the developer, then a short description. So it could look like this: SOL-CE0004-ABC-NewContactViews. We'd also of course add a fuller description in the description field for the solution but being able to see at a glance what's in a solution is helpful.

However, my main concern with this is that I'd have to keep each solution to one main customization. I'm fine doing that but wanted to get other opinions on the matter, especially regarding how to manage the number of customizations per solution. And I know there's no one right answer but I'm sure some are better than others!

I have finally developed an SDL process for our org and my last task is to determine a naming convention for our solutions. We'll be going with unmanaged solutions in all envs because of our size and small team (aka, me).

My question is, how do you name your solutions? So far we're thinking "SOL-CE####-INT-DESC" where we ID it as a solution for our DB sake, then note that it's a CE solution with a sequential number, then the initials of the developer, then a short description. So it could look like this: SOL-CE0004-ABC-NewContactViews. We'd also of course add a fuller description in the description field for the solution but being able to see at a glance what's in a solution is helpful.

However, my main concern with this is that I'd have to keep each solution to one main customization. I'm fine doing that but wanted to get other opinions on the matter, especially regarding how to manage the number of customizations per solution. And I know there's no one right answer but I'm sure some are better than others!

I have finally developed an SDL process for our org and my last task is to determine a naming convention for our solutions. We'll be going with unmanaged solutions in all envs because of our size and small team (aka, me).

My question is, how do you name your solutions? So far we're thinking "SOL-CE####-INT-DESC" where we ID it as a solution for our DB sake, then note that it's a CE solution with a sequential number, then the initials of the developer, then a short description. So it could look like this: SOL-CE0004-ABC-NewContactViews. We'd also of course add a fuller description in the description field for the solution but being able to see at a glance what's in a solution is helpful.

However, my main concern with this is that I'd have to keep each solution to one main customization. I'm fine doing that but wanted to get other opinions on the matter, especially regarding how to manage the number of customizations per solution. And I know there's no one right answer but I'm sure some are better than others!

I have finally developed an SDL process for our org and my last task is to determine a naming convention for our solutions. We'll be going with unmanaged solutions in all envs because of our size and small team (aka, me).

My question is, how do you name your solutions? So far we're thinking "SOL-CE####-INT-DESC" where we ID it as a solution for our DB sake, then note that it's a CE solution with a sequential number, then the initials of the developer, then a short description. So it could look like this: SOL-CE0004-ABC-NewContactViews. We'd also of course add a fuller description in the description field for the solution but being able to see at a glance what's in a solution is helpful.

However, my main concern with this is that I'd have to keep each solution to one main customization. I'm fine doing that but wanted to get other opinions on the matter, especially regarding how to manage the number of customizations per solution. And I know there's no one right answer but I'm sure some are better than others!

I have finally developed an SDL process for our org and my last task is to determine a naming convention for our solutions. We'll be going with unmanaged solutions in all envs because of our size and small team (aka, me).

My question is, how do you name your solutions? So far we're thinking "SOL-CE####-INT-DESC" where we ID it as a solution for our DB sake, then note that it's a CE solution with a sequential number, then the initials of the developer, then a short description. So it could look like this: SOL-CE0004-ABC-NewContactViews. We'd also of course add a fuller description in the description field for the solution but being able to see at a glance what's in a solution is helpful.

However, my main concern with this is that I'd have to keep each solution to one main customization. I'm fine doing that but wanted to get other opinions on the matter, especially regarding how to manage the number of customizations per solution. And I know there's no one right answer but I'm sure some are better than others!

I have finally developed an SDL process for our org and my last task is to determine a naming convention for our solutions. We'll be going with unmanaged solutions in all envs because of our size and small team (aka, me).

My question is, how do you name your solutions? So far we're thinking "SOL-CE####-INT-DESC" where we ID it as a solution for our DB sake, then note that it's a CE solution with a sequential number, then the initials of the developer, then a short description. So it could look like this: SOL-CE0004-ABC-NewContactViews. We'd also of course add a fuller description in the description field for the solution but being able to see at a glance what's in a solution is helpful.

However, my main concern with this is that I'd have to keep each solution to one main customization. I'm fine doing that but wanted to get other opinions on the matter, especially regarding how to manage the number of customizations per solution. And I know there's no one right answer but I'm sure some are better than others!

I have finally developed an SDL process for our org and my last task is to determine a naming convention for our solutions. We'll be going with unmanaged solutions in all envs because of our size and small team (aka, me).

My question is, how do you name your solutions? So far we're thinking "SOL-CE####-INT-DESC" where we ID it as a solution for our DB sake, then note that it's a CE solution with a sequential number, then the initials of the developer, then a short description. So it could look like this: SOL-CE0004-ABC-NewContactViews. We'd also of course add a fuller description in the description field for the solution but being able to see at a glance what's in a solution is helpful.

However, my main concern with this is that I'd have to keep each solution to one main customization. I'm fine doing that but wanted to get other opinions on the matter, especially regarding how to manage the number of customizations per solution. And I know there's no one right answer but I'm sure some are better than others!

I have finally developed an SDL process for our org and my last task is to determine a naming convention for our solutions. We'll be going with unmanaged solutions in all envs because of our size and small team (aka, me).

My question is, how do you name your solutions? So far we're thinking "SOL-CE####-INT-DESC" where we ID it as a solution for our DB sake, then note that it's a CE solution with a sequential number, then the initials of the developer, then a short description. So it could look like this: SOL-CE0004-ABC-NewContactViews. We'd also of course add a fuller description in the description field for the solution but being able to see at a glance what's in a solution is helpful.

However, my main concern with this is that I'd have to keep each solution to one main customization. I'm fine doing that but wanted to get other opinions on the matter, especially regarding how to manage the number of customizations per solution. And I know there's no one right answer but I'm sure some are better than others!

I have finally developed an SDL process for our org and my last task is to determine a naming convention for our solutions. We'll be going with unmanaged solutions in all envs because of our size and small team (aka, me).

My question is, how do you name your solutions? So far we're thinking "SOL-CE####-INT-DESC" where we ID it as a solution for our DB sake, then note that it's a CE solution with a sequential number, then the initials of the developer, then a short description. So it could look like this: SOL-CE0004-ABC-NewContactViews. We'd also of course add a fuller description in the description field for the solution but being able to see at a glance what's in a solution is helpful.

However, my main concern with this is that I'd have to keep each solution to one main customization. I'm fine doing that but wanted to get other opinions on the matter, especially regarding how to manage the number of customizations per solution. And I know there's no one right answer but I'm sure some are better than others!

I have finally developed an SDL process for our org and my last task is to determine a naming convention for our solutions. We'll be going with unmanaged solutions in all envs because of our size and small team (aka, me).

My question is, how do you name your solutions? So far we're thinking "SOL-CE####-INT-DESC" where we ID it as a solution for our DB sake, then note that it's a CE solution with a sequential number, then the initials of the developer, then a short description. So it could look like this: SOL-CE0004-ABC-NewContactViews. We'd also of course add a fuller description in the description field for the solution but being able to see at a glance what's in a solution is helpful.

However, my main concern with this is that I'd have to keep each solution to one main customization. I'm fine doing that but wanted to get other opinions on the matter, especially regarding how to manage the number of customizations per solution. And I know there's no one right answer but I'm sure some are better than others!

I have finally developed an SDL process for our org and my last task is to determine a naming convention for our solutions. We'll be going with unmanaged solutions in all envs because of our size and small team (aka, me).

My question is, how do you name your solutions? So far we're thinking "SOL-CE####-INT-DESC" where we ID it as a solution for our DB sake, then note that it's a CE solution with a sequential number, then the initials of the developer, then a short description. So it could look like this: SOL-CE0004-ABC-NewContactViews. We'd also of course add a fuller description in the description field for the solution but being able to see at a glance what's in a solution is helpful.

However, my main concern with this is that I'd have to keep each solution to one main customization. I'm fine doing that but wanted to get other opinions on the matter, especially regarding how to manage the number of customizations per solution. And I know there's no one right answer but I'm sure some are better than others!

I have finally developed an SDL process for our org and my last task is to determine a naming convention for our solutions. We'll be going with unmanaged solutions in all envs because of our size and small team (aka, me).

My question is, how do you name your solutions? So far we're thinking "SOL-CE####-INT-DESC" where we ID it as a solution for our DB sake, then note that it's a CE solution with a sequential number, then the initials of the developer, then a short description. So it could look like this: SOL-CE0004-ABC-NewContactViews. We'd also of course add a fuller description in the description field for the solution but being able to see at a glance what's in a solution is helpful.

However, my main concern with this is that I'd have to keep each solution to one main customization. I'm fine doing that but wanted to get other opinions on the matter, especially regarding how to manage the number of customizations per solution. And I know there's no one right answer but I'm sure some are better than others!

HI all,
I'm a little surprised that I haven't read anyone uses the 'patch' functionality that we have now in Power Platform.

Our approach is yet a little different to all I read above. We have one main solution that I arbitrarily called "<client name> Working Solution. This is the solution we use for all our customizations. We use the unmanaged approach, for the simple reason that it makes it easier to apply changes to the components in that solution, and we rarely ever have a situation where we would like to pull back the whole customization.

For example: the current version number is 14.0.0.0. If we start a new sprint, we would create a patch which would be 14.0.1.0. I start working on the stories in that sprint within the 14.0.1.0 solution. Then, when I release to our testing/acceptance environment, it would still be the 14.0.1.0 version. Now, when during testing or anywhere down the line (before production deploy) I have to make changes to my patch in Development environment, and do a second release to acceptance, I would update the version number to 14.0.1.1. 

Ultimately, when the patch is finalized, and we're ready to deploy to production, I'd move the patch 14.0.1.1 to production.

When all is approved and done in production, the release is over, and we're ready to work on the next sprint. I would then clone a new patch of the 14.0.1.0 solution, with version number 14.0.2.0 and continue from there.

At a certain point (after lets say 3 sprints) we would have the following solutions:

Main solution 14.0.0.0
Patch 14.0.1.0
Patch 14.0.2.0
Patch 14.0.3.0
One could go on like this as long as you like, but we've decided to create cut-off points. That could be after 5 sprints, or when we decide that the current customization wave is done and were starting to work toward a defined new milestone. At that point we would clone the solution, which basically rolls up all the patches into the main solution and upgrade it to version 15.0.0.0. Same patch process starts from there.

Any feedback or thoughts on that approach?

I have finally developed an SDL process for our org and my last task is to determine a naming convention for our solutions. We'll be going with unmanaged solutions in all envs because of our size and small team (aka, me).

My question is, how do you name your solutions? So far we're thinking "SOL-CE####-INT-DESC" where we ID it as a solution for our DB sake, then note that it's a CE solution with a sequential number, then the initials of the developer, then a short description. So it could look like this: SOL-CE0004-ABC-NewContactViews. We'd also of course add a fuller description in the description field for the solution but being able to see at a glance what's in a solution is helpful.

However, my main concern with this is that I'd have to keep each solution to one main customization. I'm fine doing that but wanted to get other opinions on the matter, especially regarding how to manage the number of customizations per solution. And I know there's no one right answer but I'm sure some are better than others!

HI all,
I'm a little surprised that I haven't read anyone uses the 'patch' functionality that we have now in Power Platform.

Our approach is yet a little different to all I read above. We have one main solution that I arbitrarily called "<client name> Working Solution. This is the solution we use for all our customizations. We use the unmanaged approach, for the simple reason that it makes it easier to apply changes to the components in that solution, and we rarely ever have a situation where we would like to pull back the whole customization.

For example: the current version number is 14.0.0.0. If we start a new sprint, we would create a patch which would be 14.0.1.0. I start working on the stories in that sprint within the 14.0.1.0 solution. Then, when I release to our testing/acceptance environment, it would still be the 14.0.1.0 version. Now, when during testing or anywhere down the line (before production deploy) I have to make changes to my patch in Development environment, and do a second release to acceptance, I would update the version number to 14.0.1.1. 

Ultimately, when the patch is finalized, and we're ready to deploy to production, I'd move the patch 14.0.1.1 to production.

When all is approved and done in production, the release is over, and we're ready to work on the next sprint. I would then clone a new patch of the 14.0.1.0 solution, with version number 14.0.2.0 and continue from there.

At a certain point (after lets say 3 sprints) we would have the following solutions:

Main solution 14.0.0.0
Patch 14.0.1.0
Patch 14.0.2.0
Patch 14.0.3.0
One could go on like this as long as you like, but we've decided to create cut-off points. That could be after 5 sprints, or when we decide that the current customization wave is done and were starting to work toward a defined new milestone. At that point we would clone the solution, which basically rolls up all the patches into the main solution and upgrade it to version 15.0.0.0. Same patch process starts from there.

Any feedback or thoughts on that approach?

I have finally developed an SDL process for our org and my last task is to determine a naming convention for our solutions. We'll be going with unmanaged solutions in all envs because of our size and small team (aka, me).

My question is, how do you name your solutions? So far we're thinking "SOL-CE####-INT-DESC" where we ID it as a solution for our DB sake, then note that it's a CE solution with a sequential number, then the initials of the developer, then a short description. So it could look like this: SOL-CE0004-ABC-NewContactViews. We'd also of course add a fuller description in the description field for the solution but being able to see at a glance what's in a solution is helpful.

However, my main concern with this is that I'd have to keep each solution to one main customization. I'm fine doing that but wanted to get other opinions on the matter, especially regarding how to manage the number of customizations per solution. And I know there's no one right answer but I'm sure some are better than others!

HI all,
I'm a little surprised that I haven't read anyone uses the 'patch' functionality that we have now in Power Platform.

Our approach is yet a little different to all I read above. We have one main solution that I arbitrarily called "<client name> Working Solution. This is the solution we use for all our customizations. We use the unmanaged approach, for the simple reason that it makes it easier to apply changes to the components in that solution, and we rarely ever have a situation where we would like to pull back the whole customization.

For example: the current version number is 14.0.0.0. If we start a new sprint, we would create a patch which would be 14.0.1.0. I start working on the stories in that sprint within the 14.0.1.0 solution. Then, when I release to our testing/acceptance environment, it would still be the 14.0.1.0 version. Now, when during testing or anywhere down the line (before production deploy) I have to make changes to my patch in Development environment, and do a second release to acceptance, I would update the version number to 14.0.1.1. 

Ultimately, when the patch is finalized, and we're ready to deploy to production, I'd move the patch 14.0.1.1 to production.

When all is approved and done in production, the release is over, and we're ready to work on the next sprint. I would then clone a new patch of the 14.0.1.0 solution, with version number 14.0.2.0 and continue from there.

At a certain point (after lets say 3 sprints) we would have the following solutions:

Main solution 14.0.0.0
Patch 14.0.1.0
Patch 14.0.2.0
Patch 14.0.3.0
One could go on like this as long as you like, but we've decided to create cut-off points. That could be after 5 sprints, or when we decide that the current customization wave is done and were starting to work toward a defined new milestone. At that point we would clone the solution, which basically rolls up all the patches into the main solution and upgrade it to version 15.0.0.0. Same patch process starts from there.

Any feedback or thoughts on that approach?

I have finally developed an SDL process for our org and my last task is to determine a naming convention for our solutions. We'll be going with unmanaged solutions in all envs because of our size and small team (aka, me).

My question is, how do you name your solutions? So far we're thinking "SOL-CE####-INT-DESC" where we ID it as a solution for our DB sake, then note that it's a CE solution with a sequential number, then the initials of the developer, then a short description. So it could look like this: SOL-CE0004-ABC-NewContactViews. We'd also of course add a fuller description in the description field for the solution but being able to see at a glance what's in a solution is helpful.

However, my main concern with this is that I'd have to keep each solution to one main customization. I'm fine doing that but wanted to get other opinions on the matter, especially regarding how to manage the number of customizations per solution. And I know there's no one right answer but I'm sure some are better than others!