Hi,
I wanted to put my app on to production but am still not confident to do it the reason is my patching is it correct or what is the best way to use it and better for performance wise also, at moment here is example my patch and it is working but takes time on run had to wait a bit? possible to improve performance and time shorten code?
Set(gblTaskLS,
Patch(
TaskLS,
If(gblRecordState,
Defaults(TaskLS),
gblTaskLS),
{
Title: DataCardValue7.Text,
Due: DataCardValue4.SelectedDate,
TransType: DataCardValue12.Selected.Value,
Notes:DataCardValue13.Text
}
));
Patch(
NotesTaskLS,
Defaults(NotesTaskLS),
{
Title: gblTaskLS.Title,
Due: gblTaskLS.Due,
TransType: DataCardValue12.Selected.Value,
Notes: gblTaskLS.Notes
}
));
Patch(
IssuesTaskLS,
Defaults(IssuesTaskLS),
{
Title: gblTaskLS.Title,
Due: gblTaskLS.Due,
TransType: DataCardValue12.Selected.Value,
IssueType: DataCardValue13.Selected.Value,
Notes: gblTaskLS.Notes
}
));
// and two more lists
Solved! Go to Solution.
Example
Instead of
Patch(
TaskLS,
If(gblRecordState,
Defaults(TaskLS),
gblTaskLS),
{
Title: DataCardValue7.Text,
Due: DataCardValue4.SelectedDate,
TransType: DataCardValue12.Selected.Value,
Notes:DataCardValue13.Text
}
));
Write it like this instead
Patch
(
TaskLS,
{
ID:If(gblRecordState,Blank(),gblTaskLS.ID),
Title: DataCardValue7.Text,
Due: DataCardValue4.SelectedDate,
TransType: DataCardValue12.Selected.Value,
Notes:DataCardValue13.Text
}
)
If the above has any issue, it may not like when you try to Patch in Blank() values, check if turning on the formula-level error management setting helps with this?
1. Click Settings
2. Click Upcoming Features
3. Toggle the Formula-level error management setting to On
Then just close the modal, see if it works.
The idea of putting the If statement inside the ID value is so that you don't have to use Defaults, and don't have to re-declare the entire record. When the ID is Blank, a new record is created anyway, using what you already provided, whereas if the ID is not blank, what you provided will be used to modify the existing record with the primary key given (ID). In SharePoint List, the ID column is the primary key column, so use the ID to identify a record uniquely for Patch.
Try to use this above guideline in rewriting your other parts of the formula.
See if it helps @PowerApps11
@PowerApps11 If you still have slowdown after applying the above, I suspect it may be how you have done the app in general. For example, that fact that you set gblTaskLS and have the Patch functions inside may be indicative that you're doing it in a way that could be causing slowdowns. You could try and not use the variable at all and see if it helps. This may be difficult to do since you may be depending on the result of this variable currently.
If the above changes to Patch do not work, try eliminating your use of the Set function and eliminate the use of the variable entirely to see if something you're doing with the variable is causing a slowdown. It may be difficult for you to do this because it depends what you're trying to accomplish exactly.
For example, if it's as simple as Patching directly from the datacards again directly to each List, try doing exactly that and don't use the variable at all.
//elsehwere in your app, have gblRecord just be the specific TaskLS record you want to change, or set it to Blank() if it should not be set at that moment.
Patch
(
TaskLS,
{
ID: If(!IsBlank(gblRecord),gblRecord.ID,Blank())
Title: DataCardValue7.Text,
Due: DataCardValue4.SelectedDate,
TransType: DataCardValue12.Selected.Value,
Notes:DataCardValue13.Text
}
);
If
(
!IsBlank(gblRecord)
,Patch
(
NotesTaskLS,
{
Title: gblRecord.Title,
Due: gblRecord.Due,
TransType: DataCardValue12.Selected.Value,
Notes: gblRecord.Notes
}
);
Patch
(
IssuesTaskLS,
{
Title: gblRecord.Title,
Due: gblRecord.Due,
TransType: DataCardValue12.Selected.Value,
IssueType: DataCardValue13.Selected.Value,
Notes: gblRecord.Notes
}
)
)
See if this might help as well. The above version eliminates 2 unnecessary patch calls for new records
or try this version if you need to create everything even when it's a new Record - just reference the data cards yet again, it might be better that way:
//elsehwere in your app, have gblRecord just be the specific TaskLS record you want to change, or set it to Blank() if it should not be set at that moment.
Patch
(
TaskLS,
{
ID: If(!IsBlank(gblRecord),gblRecord.ID,Blank())
Title: DataCardValue7.Text,
Due: DataCardValue4.SelectedDate,
TransType: DataCardValue12.Selected.Value,
Notes:DataCardValue13.Text
}
);
Patch
(
NotesTaskLS,
{
Title: DataCardValue7.Text,
Due: DataCardValue4.SelectedDate,
TransType: DataCardValue12.Selected.Value,
Notes: DataCardValue13.Text
}
);
Patch
(
IssuesTaskLS,
{
Title: DataCardValue7.Text,
Due: DataCardValue4.SelectedDate,
TransType: DataCardValue12.Selected.Value,
IssueType: DataCardValue13.Selected.Value, //???
Notes: DataCardValue13.Text
}
)
)
In the above version, it raises some questions:
1. Why do you need to duplicate values across so many lists?
2. IssueType for IssuesTaskLS says DataCardValue13.Selected.Value which was in your original formula as well, but earlier in the same Patch sequence it was DataCardValue13.Text - why is that? The form can only be one or the other for DataCardValue13, right? So there may be an actual error there or the possibility for there to be one.
I think the duplication of the data across many Lists, especially with all Lists you provided appearing to have essentially almost identical schema and receiving almost identical data may be a sign that you should model the data differently on the SharePoint List side. If you need to duplicate everything so much, then you may be using Patch calls to multiple Lists unnecessarily, causing the slowdown also unnecessarily. If that's the case then for what you need to do differently, that really depends what you actually want to do.
I am not sure the purpose of your given Lists TaskLS, NotesTaskLS, and IssuesTaskLS - they seem like duplicates of the same thing from the Patch formulas you provided, so I don't understand their purpose at all in the first place just from what you provided.
Just based on just what you provided I'd just remove all the other Lists and use just TaskLS, and then not Patch to any other List to make less Patch calls since I don't see a purpose for those Lists based on what you provided.
However, maybe those other Lists you are using do have a purpose - perhaps they have other columns that are important to you as well.
If so, then you might need to provide detail on a high level what exactly do you want to do?
I'd recommend modeling something like this
Instead of duplicating all the fields again, keep an ID of which TaskLS it is. Wait - you don't have to - it already has an ID out of the box!
Instead of duplicating the same columns and data in NotesTaskLS and IssuesTaskLS, just have one column called TaskLSID - or TaskID - or something like that - inside both Lists, and in it you can patch the ID of the TaskLS which contains the other information you need. Then you can always lookup the ID of the TaskLS even directly from NotesTaskLS and IssuesTaskLS.
However, this only makes sense if NotesTaskLS and IssuesTaskLS actually have any other columns at all to begin with besides the ones in TaskLS.
If NotesTaskLS and IssuesTaskLS really had no other columns, besides the same ones in TaskLS that you are trying to duplicate all the time in your Patch formulas to NotesTaskLS and IssuesTaskLS as you gave them - then just delete these Lists altogether and don't bother patching to them, only patch to TaskLS then!
Similarly, you could just move all columns from NotesTaskLS and IssuesTaskLS directly to TaskLS then remove both Lists NotesTaskLS and IssuesTaskLS
By the way, I wasn't sure if you were going to have more than one NotesTaskLS per TaskLS Record and more than one IssuesTaskLS per TaskLS Record.
If so, then these Patch statements don't look right at all, and the data model of your SharePoint Lists also does not look correct currently.
If you were trying to really do that (i.e. have one or more NotesTaskLS Records associated with a single TaskLS Record) you'll need to do something like what I was saying where you have a column called TaskID, so NotesTaskLS might have a TaskID column for example. So now zero, one, or more than one NotesTaskLS Records may have a TaskID that is the same across multiple NotesTaskLS Records. So from any one NotesTaskLS you can always look up which specific TaskLS Record it is associated with using
LookUp(TaskLS,ID=myCurrentNoteRecord.TaskID)
If not associated with any Record, this above LookUp returns Blank(). If it is associated with a record, it always returns exactly one Record.
To get all the multiple NotesTaskLS attached to a particular TaskLS you can do this then:
Filter(NotesTaskLS,TaskID=myCurrentTaskRecord.ID)
to get a Table of associated NotesTaskLS by the TaskLS Record's ID.
When there are no matches, the Table should be Empty
And when you Patch to NotesTaskLS you should remember on new record creation to specify for TaskID column which Task it is (i.e. specify which record of TaskLS it is by its ID), so that later you can LookUp a Task from a Note, or use Filter to get all the Notes attached to a single Task.
See if it helps @PowerApps11
The best way is to always use only 2 arguments to Patch, like this:
//To update an existing record
Patch
(
YourDataSource
{
ID: YourID //PRIMARY KEY
Field1: YourField1Contents
Field2: YourField2Contents
}
)
//To create a new record
Patch
(
YourDataSource
{
//OMIT the primary key - leave it out - to create a new record
Field1: YourField1Contents
Field2: YourField2Contents
}
)
See if it helps @PowerApps11
Example
Instead of
Patch(
TaskLS,
If(gblRecordState,
Defaults(TaskLS),
gblTaskLS),
{
Title: DataCardValue7.Text,
Due: DataCardValue4.SelectedDate,
TransType: DataCardValue12.Selected.Value,
Notes:DataCardValue13.Text
}
));
Write it like this instead
Patch
(
TaskLS,
{
ID:If(gblRecordState,Blank(),gblTaskLS.ID),
Title: DataCardValue7.Text,
Due: DataCardValue4.SelectedDate,
TransType: DataCardValue12.Selected.Value,
Notes:DataCardValue13.Text
}
)
If the above has any issue, it may not like when you try to Patch in Blank() values, check if turning on the formula-level error management setting helps with this?
1. Click Settings
2. Click Upcoming Features
3. Toggle the Formula-level error management setting to On
Then just close the modal, see if it works.
The idea of putting the If statement inside the ID value is so that you don't have to use Defaults, and don't have to re-declare the entire record. When the ID is Blank, a new record is created anyway, using what you already provided, whereas if the ID is not blank, what you provided will be used to modify the existing record with the primary key given (ID). In SharePoint List, the ID column is the primary key column, so use the ID to identify a record uniquely for Patch.
Try to use this above guideline in rewriting your other parts of the formula.
See if it helps @PowerApps11
For these
Patch(
NotesTaskLS,
Defaults(NotesTaskLS),
{
Title: gblTaskLS.Title,
Due: gblTaskLS.Due,
TransType: DataCardValue12.Selected.Value,
Notes: gblTaskLS.Notes
}
));
Patch(
IssuesTaskLS,
Defaults(IssuesTaskLS),
{
Title: gblTaskLS.Title,
Due: gblTaskLS.Due,
TransType: DataCardValue12.Selected.Value,
IssueType: DataCardValue13.Selected.Value,
Notes: gblTaskLS.Notes
}
));
Rewrite these as
Patch(
NotesTaskLS,
{
Title: gblTaskLS.Title,
Due: gblTaskLS.Due,
TransType: DataCardValue12.Selected.Value,
Notes: gblTaskLS.Notes
}
));
Patch(
IssuesTaskLS,
{
Title: gblTaskLS.Title,
Due: gblTaskLS.Due,
TransType: DataCardValue12.Selected.Value,
IssueType: DataCardValue13.Selected.Value,
Notes: gblTaskLS.Notes
}
));
@PowerApps11 If you still have slowdown after applying the above, I suspect it may be how you have done the app in general. For example, that fact that you set gblTaskLS and have the Patch functions inside may be indicative that you're doing it in a way that could be causing slowdowns. You could try and not use the variable at all and see if it helps. This may be difficult to do since you may be depending on the result of this variable currently.
If the above changes to Patch do not work, try eliminating your use of the Set function and eliminate the use of the variable entirely to see if something you're doing with the variable is causing a slowdown. It may be difficult for you to do this because it depends what you're trying to accomplish exactly.
For example, if it's as simple as Patching directly from the datacards again directly to each List, try doing exactly that and don't use the variable at all.
//elsehwere in your app, have gblRecord just be the specific TaskLS record you want to change, or set it to Blank() if it should not be set at that moment.
Patch
(
TaskLS,
{
ID: If(!IsBlank(gblRecord),gblRecord.ID,Blank())
Title: DataCardValue7.Text,
Due: DataCardValue4.SelectedDate,
TransType: DataCardValue12.Selected.Value,
Notes:DataCardValue13.Text
}
);
If
(
!IsBlank(gblRecord)
,Patch
(
NotesTaskLS,
{
Title: gblRecord.Title,
Due: gblRecord.Due,
TransType: DataCardValue12.Selected.Value,
Notes: gblRecord.Notes
}
);
Patch
(
IssuesTaskLS,
{
Title: gblRecord.Title,
Due: gblRecord.Due,
TransType: DataCardValue12.Selected.Value,
IssueType: DataCardValue13.Selected.Value,
Notes: gblRecord.Notes
}
)
)
See if this might help as well. The above version eliminates 2 unnecessary patch calls for new records
or try this version if you need to create everything even when it's a new Record - just reference the data cards yet again, it might be better that way:
//elsehwere in your app, have gblRecord just be the specific TaskLS record you want to change, or set it to Blank() if it should not be set at that moment.
Patch
(
TaskLS,
{
ID: If(!IsBlank(gblRecord),gblRecord.ID,Blank())
Title: DataCardValue7.Text,
Due: DataCardValue4.SelectedDate,
TransType: DataCardValue12.Selected.Value,
Notes:DataCardValue13.Text
}
);
Patch
(
NotesTaskLS,
{
Title: DataCardValue7.Text,
Due: DataCardValue4.SelectedDate,
TransType: DataCardValue12.Selected.Value,
Notes: DataCardValue13.Text
}
);
Patch
(
IssuesTaskLS,
{
Title: DataCardValue7.Text,
Due: DataCardValue4.SelectedDate,
TransType: DataCardValue12.Selected.Value,
IssueType: DataCardValue13.Selected.Value, //???
Notes: DataCardValue13.Text
}
)
)
In the above version, it raises some questions:
1. Why do you need to duplicate values across so many lists?
2. IssueType for IssuesTaskLS says DataCardValue13.Selected.Value which was in your original formula as well, but earlier in the same Patch sequence it was DataCardValue13.Text - why is that? The form can only be one or the other for DataCardValue13, right? So there may be an actual error there or the possibility for there to be one.
I think the duplication of the data across many Lists, especially with all Lists you provided appearing to have essentially almost identical schema and receiving almost identical data may be a sign that you should model the data differently on the SharePoint List side. If you need to duplicate everything so much, then you may be using Patch calls to multiple Lists unnecessarily, causing the slowdown also unnecessarily. If that's the case then for what you need to do differently, that really depends what you actually want to do.
I am not sure the purpose of your given Lists TaskLS, NotesTaskLS, and IssuesTaskLS - they seem like duplicates of the same thing from the Patch formulas you provided, so I don't understand their purpose at all in the first place just from what you provided.
Just based on just what you provided I'd just remove all the other Lists and use just TaskLS, and then not Patch to any other List to make less Patch calls since I don't see a purpose for those Lists based on what you provided.
However, maybe those other Lists you are using do have a purpose - perhaps they have other columns that are important to you as well.
If so, then you might need to provide detail on a high level what exactly do you want to do?
I'd recommend modeling something like this
Instead of duplicating all the fields again, keep an ID of which TaskLS it is. Wait - you don't have to - it already has an ID out of the box!
Instead of duplicating the same columns and data in NotesTaskLS and IssuesTaskLS, just have one column called TaskLSID - or TaskID - or something like that - inside both Lists, and in it you can patch the ID of the TaskLS which contains the other information you need. Then you can always lookup the ID of the TaskLS even directly from NotesTaskLS and IssuesTaskLS.
However, this only makes sense if NotesTaskLS and IssuesTaskLS actually have any other columns at all to begin with besides the ones in TaskLS.
If NotesTaskLS and IssuesTaskLS really had no other columns, besides the same ones in TaskLS that you are trying to duplicate all the time in your Patch formulas to NotesTaskLS and IssuesTaskLS as you gave them - then just delete these Lists altogether and don't bother patching to them, only patch to TaskLS then!
Similarly, you could just move all columns from NotesTaskLS and IssuesTaskLS directly to TaskLS then remove both Lists NotesTaskLS and IssuesTaskLS
By the way, I wasn't sure if you were going to have more than one NotesTaskLS per TaskLS Record and more than one IssuesTaskLS per TaskLS Record.
If so, then these Patch statements don't look right at all, and the data model of your SharePoint Lists also does not look correct currently.
If you were trying to really do that (i.e. have one or more NotesTaskLS Records associated with a single TaskLS Record) you'll need to do something like what I was saying where you have a column called TaskID, so NotesTaskLS might have a TaskID column for example. So now zero, one, or more than one NotesTaskLS Records may have a TaskID that is the same across multiple NotesTaskLS Records. So from any one NotesTaskLS you can always look up which specific TaskLS Record it is associated with using
LookUp(TaskLS,ID=myCurrentNoteRecord.TaskID)
If not associated with any Record, this above LookUp returns Blank(). If it is associated with a record, it always returns exactly one Record.
To get all the multiple NotesTaskLS attached to a particular TaskLS you can do this then:
Filter(NotesTaskLS,TaskID=myCurrentTaskRecord.ID)
to get a Table of associated NotesTaskLS by the TaskLS Record's ID.
When there are no matches, the Table should be Empty
And when you Patch to NotesTaskLS you should remember on new record creation to specify for TaskID column which Task it is (i.e. specify which record of TaskLS it is by its ID), so that later you can LookUp a Task from a Note, or use Filter to get all the Notes attached to a single Task.
See if it helps @PowerApps11
Hi @poweractivate
Thank you for you clear information , you right some of the patch statements was just copy not the actual the one using, wanted to know why taking time for the patching, put it looks as you said no need to use defaults that helped the speed also below helped me thank you so much.
ID: If(gblRecordState,Blank(),gblTaskLS.ID)
For sure you made me understand how to use patch correctly.
@poweractivate in the come days will create new thread asking the best way to use ForAll and how to add ForAll a variable to reuse it like get all ID's just patched ForAll and attached them on to another list like notes.
Do you mind if I tag you?
@PowerApps11 wrote:Hi @poweractivate
ForAll and how to add ForAll a variable to reuse it like get all ID's just patched ForAll and attached them on to another list like notes.Do you mind if I tag you?
You may tag me.
If you do not use the output table of ForAll, try not to use it at all.
Try not to use ForAll as a for loop.
In general use ForAll inside Patch, do not use ForAll outside of Patch,
In general use Patch outside ForAll, do not use Patch inside ForAll
it's better to Patch just once on a whole Table,
than patch multiple times inside a ForAll whose outer table is never being used.
You may give a specific example if you want of your use of ForAll so I can check it, the above advice may be hard to apply sometimes.
Here is a general advice I have for using Patch outside ForAll:
//usually bad
ForAll
(
Patch
(
//BAD
)
)
//usually good
Patch
(
ForAll
(
//GOOD
)
)
@poweractivate
Yes I use
Patch
(
ForAll
(
//GOOD
)
)
But hard to find how can I add variable inside the ForAll so I can reuse it and get the id's just just patched ForAll
for example my case
Patch
NotesTaskLS,
ForAll(galMulti.AllItems,
{
Title: DataCardValue7.Text,
Due: DataCardValue4.SelectedDate,
TransType: DataCardValue12.Selected.Value,
Notes: DataCardValue13.Text
}
);
Patch
(
IssuesTaskLS,
{
Title: DataCardValue7.Text,
Due: DataCardValue4.SelectedDate,
TransType: DataCardValue12.Selected.Value,
IssueType: DataCardValue13.Selected.Value,
TaskLSID: xxxxx.ID // i want the id of the NotesTaskLS
Notes: DataCardValue13.Text
}
)
)
Is that looks right for you? or I need to do differently please?
Dear Community Members, We'd like to let you know of an upcoming change to the community platform: starting July 16th, the platform will transition to a READ ONLY mode until July 22nd. During this period, members will not be able to Kudo, Comment, or Reply to any posts. On July 22nd, please be on the lookout for a message sent to the email address registered on your community profile. This email is crucial as it will contain your unique code and link to register for the new platform encompassing all of the communities. What to Expect in the New Community: A more unified experience where all products, including Power Apps, Power Automate, Copilot Studio, and Power Pages, will be accessible from one community.Community Blogs that you can syndicate and link to for automatic updates. We appreciate your understanding and cooperation during this transition. Stay tuned for the exciting new features and a seamless community experience ahead!
We are excited to announce the Summer of Solutions Challenge! This challenge is kicking off on Monday, June 17th and will run for (4) weeks. The challenge is open to all Power Platform (Power Apps, Power Automate, Copilot Studio & Power Pages) community members. We invite you to participate in a quest to provide solutions in the Forums to as many questions as you can. Answers can be provided in all the communities. Entry Period: This Challenge will consist of four weekly Entry Periods as follows (each an “Entry Period”) - 12:00 a.m. PT on June 17, 2024 – 11:59 p.m. PT on June 23, 2024 - 12:00 a.m. PT on June 24, 2024 – 11:59 p.m. PT on June 30, 2024 - 12:00 a.m. PT on July 1, 2024 – 11:59 p.m. PT on July 7, 2024 - 12:00 a.m. PT on July 8, 2024 – 11:59 p.m. PT on July 14, 2024 Entries will be eligible for the Entry Period in which they are received and will not carryover to subsequent weekly entry periods. You must enter into each weekly Entry Period separately. How to Enter: We invite you to participate in a quest to provide "Accepted Solutions" to as many questions as you can. Answers can be provided in all the communities. Users must provide a solution which can be an “Accepted Solution” in the Forums in all of the communities and there are no limits to the number of “Accepted Solutions” that a member can provide for entries in this challenge, but each entry must be substantially unique and different. Winner Selection and Prizes: At the end of each week, we will list the top ten (10) Community users which will consist of: 5 Community Members & 5 Super Users and they will advance to the final drawing. We will post each week in the News & Announcements the top 10 Solution providers. At the end of the challenge, we will add all of the top 10 weekly names and enter them into a random drawing. Then we will randomly select ten (10) winners (5 Community Members & 5 Super Users) from among all eligible entrants received across all weekly Entry Periods to receive the prize listed below. If a winner declines, we will draw again at random for the next winner. A user will only be able to win once overall. If they are drawn multiple times, another user will be drawn at random. Individuals will be contacted before the announcement with the opportunity to claim or deny the prize. Once all of the winners have been notified, we will post in the News & Announcements of each community with the list of winners. Each winner will receive one (1) Pass to the Power Platform Conference in Las Vegas, Sep. 18-20, 2024 ($1800 value). NOTE: Prize is for conference attendance only and any other costs such as airfare, lodging, transportation, and food are the sole responsibility of the winner. Tickets are not transferable to any other party or to next year’s event. ** PLEASE SEE THE ATTACHED RULES for this CHALLENGE** Week 1 Results: Congratulations to the Week 1 qualifiers, you are being entered in the random drawing that will take place at the end of the challenge. Community MembersNumber of SolutionsSuper UsersNumber of Solutions @anandm08 23 @WarrenBelz 31 @DBO_DV 10 @Amik 19 AmínAA 6 @mmbr1606 12 @rzuber 4 @happyume 7 @Giraldoj 3@ANB 6 (tie) @SpongYe 6 (tie) Week 2 Results: Congratulations to the Week 2 qualifiers, you are being entered in the random drawing that will take place at the end of the challenge. Community MembersSolutionsSuper UsersSolutions @anandm08 10@WarrenBelz 25 @DBO_DV 6@mmbr1606 14 @AmínAA 4 @Amik 12 @royg 3 @ANB 10 @AllanDeCastro 2 @SunilPashikanti 5 @Michaelfp 2 @FLMike 5 @eduardo_izzo 2 Meekou 2 @rzuber 2 @Velegandla 2 @PowerPlatform-P 2 @Micaiah 2 Week 3 Results: Congratulations to the Week 3 qualifiers, you are being entered in the random drawing that will take place at the end of the challenge. Week 3:Community MembersSolutionsSuper UsersSolutionsPower Apps anandm0861WarrenBelz86DBO_DV25Amik66Michaelfp13mmbr160647Giraldoj13FLMike31AmínAA13SpongYe27 Week 4 Results: Congratulations to the Week 4 qualifiers, you are being entered in the random drawing that will take place at the end of the challenge. Week 4:Community MembersSolutionsSuper UsersSolutionsPower Apps DBO-DV21WarranBelz26Giraldoj7mmbr160618Muzammmil_0695067Amik14samfawzi_acml6FLMike12tzuber6ANB8 SunilPashikanti8
On July 16, 2024, we published the 2024 release wave 2 plans for Microsoft Dynamics 365 and Microsoft Power Platform. These plans are a compilation of the new capabilities planned to be released between October 2024 to March 2025. This release introduces a wealth of new features designed to enhance customer understanding and improve overall user experience, showcasing our dedication to driving digital transformation for our customers and partners. The upcoming wave is centered around utilizing advanced AI and Microsoft Copilot technologies to enhance user productivity and streamline operations across diverse business applications. These enhancements include intelligent automation, AI-powered insights, and immersive user experiences that are designed to break down barriers between data, insights, and individuals. Watch a summary of the release highlights. Discover the latest features that empower organizations to operate more efficiently and adaptively. From AI-driven sales insights and customer service enhancements to predictive analytics in supply chain management and autonomous financial processes, the new capabilities enable businesses to proactively address challenges and capitalize on opportunities.
We're embarking on a journey to enhance your experience by transitioning to a new community platform. Our team has been diligently working to create a fresh community site, leveraging the very Dynamics 365 and Power Platform tools our community advocates for. We started this journey with transitioning Copilot Studio forums and blogs in June. The move marks the beginning of a new chapter, and we're eager for you to be a part of it. The rest of the Power Platform product sites will be moving over this summer. Stay tuned for more updates as we get closer to the launch. We can't wait to welcome you to our new community space, designed with you in mind. Let's connect, learn, and grow together. Here's to new beginnings and endless possibilities! If you have any questions, observations or concerns throughout this process please go to https://aka.ms/PPCommSupport. To stay up to date on the latest details of this migration and other important Community updates subscribe to our News and Announcements forums: Copilot Studio, Power Apps, Power Automate, Power Pages