cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
ericonline
Community Champion
Community Champion

Data Management Best Practices

I'm not a database person so I don't know what the traditional data design pattern is for this problem, but here goes. 

 

  • Users have the ability to add any number of items to a single entity
    • Examples
      • Photo entity: User can take 1 photo or 40 photos
      • Activity entity: User can add multiple events throughout the day each with durations and comments
  • The problem I have is that I end up with a Sharepoint list with 100 columns like: 
    • event1_type, event1_activity, event1_duration, event1_comments
    • event2_type, event2_activity, event2_duration, event2_comments
    • etc. 

How do I approach this better WITH REPORTING IN MIND? Its getting unruly to maintain. 

 

Thanks

2 ACCEPTED SOLUTIONS

Accepted Solutions
RusselThomas
Community Champion
Community Champion

 

Hi ericonline,

 

I'm no specialist either, but this can get quite complicated to explain so I'll try keep is as simple as possible.

 

Databases help us to relate data - meaning when you have a one-to-many relationship between entities, it's usually better to keep the "one" in one table and reference it in the "many" table.  This helps segment and manage your entities and avoid 300-column tables.

 

I consider entities to be a 'category' - so in your example the entities would be Events, Photos and possibly Comments

 

When entity fields (columns in the table) have a one-to-one relationship, then it's probably better to keep the data together in the same table.  Sometimes you have nested one-to-many relationships, which also complicate matters...

 

So to illustrate this, I'll try work through a simplified example - it might not be identical to your use case, but it's the concept we're trying to understand here;

 

  • One Event has one Title, one duration, one location - these fields have a one-to-one relationship with the Event entity
    • That same event has many Photos
      • Each Photo may have many Comments about the Photo

Based on the above, I would construct my database as follows;

 

One Event Table

One EventPhotos Table

One PhotoComments Table

 

Because we often use SharePoint Lists as our tables, you can just replace "Table" for "List" wherever you see it here - the construct is the same - an entity that has columns and rows.

 

My Event table would have just these Columns

[ID], EventTitle, EventDuration, EventLocation

 

Where [ID] is a unique reference column in that Table for that row of data. I've put it in square brackets here because when you're using SharePoint, you don't need to create this column - SharePoint creates it for you.  Every single List has an ID column that is unique for every single row of data.

 

 

This unique reference is what you use to link data in other tables to this event and is typically referred to as a Primary Key, meaning the key that identifies data in this table.

If you don't see it in your list, it's just hidden - go into the view settings for the list and tick the ID column 🙂

 

While it's generated automatically and consecutively, it doesn't need to be consecutive - it just needs all the values in the column to be unique.

 

Now, for photos, comments or any other data that might be linked to the event you would then build a table that logically groups that particular data;

 

EventPhotos Table:

[ID], PhotoURL, Name, TakenBy, TakenDate, EventID

 

Where EventID is the value of the Primary Key column of the Event in the Event Table I want to link that photo to.  I have to create this column, and I have to put the data in.  The idea here is that when I upload Photo's, I should already know which event those Photo's belong to, so I can put that Events [ID] number into this column.  This is referred to as a Foreign Key, meaning data that can identify data in another table.

 

You would then do the same process for the PhotoComments table, except here it's the one Photo you want to link to - so here you need the Photo's [ID] to link comments.

 

 

It's important to do this as you create the data - trying to link stuff afterwards will require quite a bit of filtering and manual updates.  If you have one big table, you would need to either start again, or manually pull the data out and put it into it's separate tables, updating the foreign keys as you do - quite an exercise.

 

Lastly, with reporting in mind I have two words for you - Power BI 

With it you can ues the same techniques to relate data from different tables.- and it can easily connect to SharePoint lists as well as autorefresh data it gets from them - but that's a post for the Power BI community 🙂

 

All of this is quite hard to explain with just text, hopefully this image will help;

DB1.jpg

 

So for the above, if I have an Gallery in PowerApps named 'eventGallery' with EventTable as Items, I could then have a second gallery with

Filter(EventPhotos, EventID=eventGallery.Selected.ID) 

as Items.  This will populate my second gallery with all the photos linked to whichever event is selected in the first gallery.

 

This approach allows me to fetch all the data related to a specific event from various places and present it on the same screen.

 

Hope this helps 🙂

 

RT

View solution in original post

Hi seadude,

 

I'm definitely no DB designer, so calling my process a workflow is a little insulting to workflows! 🙂
I'm pretty lazy, and nowhere near as structured as I should be.  I tend to build on the fly, which is admittedly not the best practice and has gotten me into some tight corners where I've had to redesign. 

This is an area I should also work on for better apps - I can share my approach, but it's by no means the best, or even a good approach - that's my disclaimer done with!

 

Designing for me is about finding the right balance between categorising data into logical groups or entities while keeping the number of lookups (joins) between them to the absolute minimum required - then it's about performance, like indexing the columns you're likely to use most for filtering or lookups and using as flat as possible column types - like plain text or number.  This is especially important for delegation limitations and list view thresholds on SharePoint lists when using PowerApps.

It's useful to know what data you need 'at rest' vs what you can derive efficiently at 'runtime'.

 

For example, person/group columns in SharePoint are a great integration for identifying AD users, but you actually just need the email address of the user to get more profile data in your app using something like the Office365Users connector. 

Filtering on a person/group column from PowerApps always used to cause delegation issues for me, but filtering on an indexed plain text "userEmail" column that you populate yourself is far easier. 

I also stay away from complicated columns like choice and lookups in SharePoint - just personal preference, as I prefer to use PowerApps to define and manage user choices and/or data lookups.

 

For design and planning, I usually start with pen and paper (or draw in OneNote).  I start with the basic functions of the app, get an idea of the screens, then drop down to required data sources and outline the entities and their relationships - from there, Excel for quick concepts and dummy data creation, MS Access for more specific table linking visualisation.  

 

The nice thing about using Excel or Access with SharePoint is that you can easily export your tables to SharePoint Lists once you've built them. There are a few drawbacks to using this method though - this is a once-off export which creates the list - I haven't seen a way to update a list from excel without using Flow. 

Excel is also not great for showing relationships, but MS Access has a great visualisation view for relating and linking tables. 

 

 

If you're using SQL, the database designer also has a good design view, but this might be overkill.  

Power BI desktop has a similar visualisation capability, but it's more predisposed to having tables with data already available that you can then link, as opposed to designing from scratch. For something more complicated you could check online for free design tools like SQLdbm (I'm sure there are plenty of others), but I can't speak to usability or exportability there.

 

Other people on this forum likely have much more efficient and structured approaches than I do, so I'd love to see their responses - (I'm looking at you @mr-dang ;)) but in the end it comes down to what works for you and your particular app/data 

 

Hope this helps, and watching this thread with interest 🙂

 


RT

 

 

View solution in original post

9 REPLIES 9
RusselThomas
Community Champion
Community Champion

 

Hi ericonline,

 

I'm no specialist either, but this can get quite complicated to explain so I'll try keep is as simple as possible.

 

Databases help us to relate data - meaning when you have a one-to-many relationship between entities, it's usually better to keep the "one" in one table and reference it in the "many" table.  This helps segment and manage your entities and avoid 300-column tables.

 

I consider entities to be a 'category' - so in your example the entities would be Events, Photos and possibly Comments

 

When entity fields (columns in the table) have a one-to-one relationship, then it's probably better to keep the data together in the same table.  Sometimes you have nested one-to-many relationships, which also complicate matters...

 

So to illustrate this, I'll try work through a simplified example - it might not be identical to your use case, but it's the concept we're trying to understand here;

 

  • One Event has one Title, one duration, one location - these fields have a one-to-one relationship with the Event entity
    • That same event has many Photos
      • Each Photo may have many Comments about the Photo

Based on the above, I would construct my database as follows;

 

One Event Table

One EventPhotos Table

One PhotoComments Table

 

Because we often use SharePoint Lists as our tables, you can just replace "Table" for "List" wherever you see it here - the construct is the same - an entity that has columns and rows.

 

My Event table would have just these Columns

[ID], EventTitle, EventDuration, EventLocation

 

Where [ID] is a unique reference column in that Table for that row of data. I've put it in square brackets here because when you're using SharePoint, you don't need to create this column - SharePoint creates it for you.  Every single List has an ID column that is unique for every single row of data.

 

 

This unique reference is what you use to link data in other tables to this event and is typically referred to as a Primary Key, meaning the key that identifies data in this table.

If you don't see it in your list, it's just hidden - go into the view settings for the list and tick the ID column 🙂

 

While it's generated automatically and consecutively, it doesn't need to be consecutive - it just needs all the values in the column to be unique.

 

Now, for photos, comments or any other data that might be linked to the event you would then build a table that logically groups that particular data;

 

EventPhotos Table:

[ID], PhotoURL, Name, TakenBy, TakenDate, EventID

 

Where EventID is the value of the Primary Key column of the Event in the Event Table I want to link that photo to.  I have to create this column, and I have to put the data in.  The idea here is that when I upload Photo's, I should already know which event those Photo's belong to, so I can put that Events [ID] number into this column.  This is referred to as a Foreign Key, meaning data that can identify data in another table.

 

You would then do the same process for the PhotoComments table, except here it's the one Photo you want to link to - so here you need the Photo's [ID] to link comments.

 

 

It's important to do this as you create the data - trying to link stuff afterwards will require quite a bit of filtering and manual updates.  If you have one big table, you would need to either start again, or manually pull the data out and put it into it's separate tables, updating the foreign keys as you do - quite an exercise.

 

Lastly, with reporting in mind I have two words for you - Power BI 

With it you can ues the same techniques to relate data from different tables.- and it can easily connect to SharePoint lists as well as autorefresh data it gets from them - but that's a post for the Power BI community 🙂

 

All of this is quite hard to explain with just text, hopefully this image will help;

DB1.jpg

 

So for the above, if I have an Gallery in PowerApps named 'eventGallery' with EventTable as Items, I could then have a second gallery with

Filter(EventPhotos, EventID=eventGallery.Selected.ID) 

as Items.  This will populate my second gallery with all the photos linked to whichever event is selected in the first gallery.

 

This approach allows me to fetch all the data related to a specific event from various places and present it on the same screen.

 

Hope this helps 🙂

 

RT

Great write up and explanation @RusselThomas! This is exactly what I was looking for (this is @ericonline's non-work persona 🙂 ) Looks like I have to dust off my old SQL notes and get into 1st Normal, 2nd Normal, etc!

 

How are you mocking up your data relationships (the table images) for Sharepoint? In Excel then screenshot or some Visio stencils? I'd like to approach this part of app building more formally and it really looks like you have a lead on this. Care to share your workflow for building data tables?

Hi seadude,

 

I'm definitely no DB designer, so calling my process a workflow is a little insulting to workflows! 🙂
I'm pretty lazy, and nowhere near as structured as I should be.  I tend to build on the fly, which is admittedly not the best practice and has gotten me into some tight corners where I've had to redesign. 

This is an area I should also work on for better apps - I can share my approach, but it's by no means the best, or even a good approach - that's my disclaimer done with!

 

Designing for me is about finding the right balance between categorising data into logical groups or entities while keeping the number of lookups (joins) between them to the absolute minimum required - then it's about performance, like indexing the columns you're likely to use most for filtering or lookups and using as flat as possible column types - like plain text or number.  This is especially important for delegation limitations and list view thresholds on SharePoint lists when using PowerApps.

It's useful to know what data you need 'at rest' vs what you can derive efficiently at 'runtime'.

 

For example, person/group columns in SharePoint are a great integration for identifying AD users, but you actually just need the email address of the user to get more profile data in your app using something like the Office365Users connector. 

Filtering on a person/group column from PowerApps always used to cause delegation issues for me, but filtering on an indexed plain text "userEmail" column that you populate yourself is far easier. 

I also stay away from complicated columns like choice and lookups in SharePoint - just personal preference, as I prefer to use PowerApps to define and manage user choices and/or data lookups.

 

For design and planning, I usually start with pen and paper (or draw in OneNote).  I start with the basic functions of the app, get an idea of the screens, then drop down to required data sources and outline the entities and their relationships - from there, Excel for quick concepts and dummy data creation, MS Access for more specific table linking visualisation.  

 

The nice thing about using Excel or Access with SharePoint is that you can easily export your tables to SharePoint Lists once you've built them. There are a few drawbacks to using this method though - this is a once-off export which creates the list - I haven't seen a way to update a list from excel without using Flow. 

Excel is also not great for showing relationships, but MS Access has a great visualisation view for relating and linking tables. 

 

 

If you're using SQL, the database designer also has a good design view, but this might be overkill.  

Power BI desktop has a similar visualisation capability, but it's more predisposed to having tables with data already available that you can then link, as opposed to designing from scratch. For something more complicated you could check online for free design tools like SQLdbm (I'm sure there are plenty of others), but I can't speak to usability or exportability there.

 

Other people on this forum likely have much more efficient and structured approaches than I do, so I'd love to see their responses - (I'm looking at you @mr-dang ;)) but in the end it comes down to what works for you and your particular app/data 

 

Hope this helps, and watching this thread with interest 🙂

 


RT

 

 

@RusselThomas

 

I'm in the same boat, PowerApps off-the-cuff, everytime. I like the term "canvas" app because I feel like an artist when building! Unfortunately, like you mentioned, this can sometimes lead to rework further down the road. 

 

I'll look into using the Access table tool (I think I have Access) and at the least, work with Excel to model my data out a bit more. I really appreciate the insights and look forward to working with you in the forums as time goes on. 

 

Chat soon

Just jumped into Access 2016 Desktop app to mess around with designing tables and data relationships. I do believe this will take my PowerApps to the next level. This IS indeed a nice tool. 

 

(Hint: Click "Database Tools" / "Relationships" or / "Database Documenter" to get creative!)

Yep, used to use Access to design way back before SQL got it's own designer - still love it 🙂

Hi @RusselThomas

 

Actively referring to this conversation here and have another question for you. 

 

  • What about many-to-many relationships? How do I create table connections for these? 

 

Example: 

  • Each event has many volunteers and I might use many volunteers for an event. 

 

I'm trying apply what you wrote above, but I can't seem to get away from having a column with multiple values in each cell. This is tough to parse and VERY tough to write to. Am I missing something or is this a tough thing to do with Sharepoint lists in general? 

 

Thanks for your time!

If I may be so bold, I'll offer my take on the many-to-many. In SQL, I would make a table that has three items: a primary key (ID), a foreign key reference for the event ID, and a foreign key reference for the volunteer ID. That way, you could tie events to any number of volunteers and any number of events to each volunteer. Example:

 

Events Table:

ID          Event          Date

1           Bowling       2018-08-21

2           Fishing        2018-09-25

3           Curling        2018-10-23

 

Volunteers Table:

ID          Name

1           Bill

2           Ted

3           Rufus

 

EventVolunteers Table:

ID          EventID          VolunteerID

1           1                     1

2           1                     2

3           2                     1

4           2                     2

5           3                     1

6           3                     2

7           3                     3

 

In the EventVolunteers table, we see that Bill and Ted go Bowling (Volunteer ID's 1 & 2 with Event ID 1) and Fishing (Volunteer ID's 1 & 2 with Event ID 2), but for Curling they take Rufus along (Volunteer ID's 1, 2, & 3 with Event ID 3). Many Events, many Volunteers, able to be filtered by either column to check Events to Volunteers or Volunteers to Events. 

 

To use @RusselThomas 's first example, it would be like if you made a table with just the yellow highlighted columns and an auto-generated ID column. 

 

I don't know SharePoint that well, so I don't know if you can do those types of relationships or how it handles them, but with SQL it isn't bad at all. I would imagine that you could create a pseudo-connecting table by using a PowerApp to write the ID's as integers to a list in SharePoint that has an auto-generated ID and then use PowerApps/PowerBI to reference them with filtering. They may not be formally connected, but it could work in a pinch. Problems may arise if you delete Volunteers or Events that have IDs in the EventVolunteers table, leaving them orphaned. SQL has ways to deal with this but I don't know about SharePoint. The pseudo-connecting table idea would have to be dealt with manually or using PowerApps to look for the orphaned keys and remove them.

 

Forgive the intrusion but hopefully this is relevant. 

@wyotim's response is what I would have said - I call it a sandwich table, I think it's actually called a junction table, so another way of looking at his example;

 

Events:

[ID], Event, Date

 

Volunteers:

[ID], Name, Surname, Phone Number

 

EventVolunteers:

[ID], EventID, VolunteerID

 

 

Then it's really a matter of what you're trying to show in which control and how you want to show it that will determine your filter/lookup commands.

 

Kind regards,

 

RT

Helpful resources

Announcements

Exclusive LIVE Community Event: Power Apps Copilot Coffee Chat with Copilot Studio Product Team

  It's time for the SECOND Power Apps Copilot Coffee Chat featuring the Copilot Studio product team, which will be held LIVE on April 3, 2024 at 9:30 AM Pacific Daylight Time (PDT).     This is an incredible opportunity to connect with members of the Copilot Studio product team and ask them anything about Copilot Studio. We'll share our special guests with you shortly--but we want to encourage to mark your calendars now because you will not want to miss the conversation.   This live event will give you the unique opportunity to learn more about Copilot Studio plans, where we’ll focus, and get insight into upcoming features. We’re looking forward to hearing from the community, so bring your questions!   TO GET ACCESS TO THIS EXCLUSIVE AMA: Kudo this post to reserve your spot! Reserve your spot now by kudoing this post.  Reservations will be prioritized on when your kudo for the post comes through, so don't wait! Click that "kudo button" today.   Invitations will be sent on April 2nd.Users posting Kudos after April 2nd. at 9AM PDT may not receive an invitation but will be able to view the session online after conclusion of the event. Give your "kudo" today and mark your calendars for April 3rd, 2024 at 9:30 AM PDT and join us for an engaging and informative session!

Tuesday Tip: Unlocking Community Achievements and Earning Badges

TUESDAY TIPS are our way of communicating helpful things we've learned or shared that have helped members of the Community. Whether you're just getting started or you're a seasoned pro, Tuesday Tips will help you know where to go, what to look for, and navigate your way through the ever-growing--and ever-changing--world of the Power Platform Community! We cover basics about the Community, provide a few "insider tips" to make your experience even better, and share best practices gleaned from our most active community members and Super Users.   With so many new Community members joining us each week, we'll also review a few of our "best practices" so you know just "how" the Community works, so make sure to watch the News & Announcements each week for the latest and greatest Tuesday Tips!     THIS WEEK'S TIP: Unlocking Achievements and Earning BadgesAcross the Communities, you'll see badges on users profile that recognize and reward their engagement and contributions. These badges each signify a different achievement--and all of those achievements are available to any Community member! If you're a seasoned pro or just getting started, you too can earn badges for the great work you do. Check out some details on Community badges below--and find out more in the detailed link at the end of the article!       A Diverse Range of Badges to Collect The badges you can earn in the Community cover a wide array of activities, including: Kudos Received: Acknowledges the number of times a user’s post has been appreciated with a “Kudo.”Kudos Given: Highlights the user’s generosity in recognizing others’ contributions.Topics Created: Tracks the number of discussions initiated by a user.Solutions Provided: Celebrates the instances where a user’s response is marked as the correct solution.Reply: Counts the number of times a user has engaged with community discussions.Blog Contributor: Honors those who contribute valuable content and are invited to write for the community blog.       A Community Evolving Together Badges are not only a great way to recognize outstanding contributions of our amazing Community members--they are also a way to continue fostering a collaborative and supportive environment. As you continue to share your knowledge and assist each other these badges serve as a visual representation of your valuable contributions.   Find out more about badges in these Community Support pages in each Community: All About Community Badges - Power Apps CommunityAll About Community Badges - Power Automate CommunityAll About Community Badges - Copilot Studio CommunityAll About Community Badges - Power Pages Community

Tuesday Tips: Powering Up Your Community Profile

TUESDAY TIPS are our way of communicating helpful things we've learned or shared that have helped members of the Community. Whether you're just getting started or you're a seasoned pro, Tuesday Tips will help you know where to go, what to look for, and navigate your way through the ever-growing--and ever-changing--world of the Power Platform Community! We cover basics about the Community, provide a few "insider tips" to make your experience even better, and share best practices gleaned from our most active community members and Super Users.   With so many new Community members joining us each week, we'll also review a few of our "best practices" so you know just "how" the Community works, so make sure to watch the News & Announcements each week for the latest and greatest Tuesday Tips!   This Week's Tip: Power Up Your Profile!  🚀 It's where every Community member gets their start, and it's essential that you keep it updated! Your Community User Profile is how you're able to get messages, post solutions, ask questions--and as you rank up, it's where your badges will appear and how you'll be known when you start blogging in the Community Blog. Your Community User Profile is how the Community knows you--so it's essential that it works the way you need it to! From changing your username to updating contact information, this Knowledge Base Article is your best resource for powering up your profile.     Password Puzzles? No Problem! Find out how to sync your Azure AD password with your community account, ensuring a seamless sign-in. No separate passwords to remember! Job Jumps & Email Swaps Changed jobs? Got a new email? Fear not! You'll find out how to link your shiny new email to your existing community account, keeping your contributions and connections intact. Username Uncertainties Unraveled Picking the perfect username is crucial--and sometimes the original choice you signed up with doesn't fit as well as you may have thought. There's a quick way to request an update here--but remember, your username is your community identity, so choose wisely. "Need Admin Approval" Warning Window? If you see this error message while using the community, don't worry. A simple process will help you get where you need to go. If you still need assistance, find out how to contact your Community Support team. Whatever you're looking for, when it comes to your profile, the Community Account Support Knowledge Base article is your treasure trove of tips as you navigate the nuances of your Community Profile. It’s the ultimate resource for keeping your digital identity in tip-top shape while engaging with the Power Platform Community. So, dive in and power up your profile today!  💪🚀   Community Account Support | Power Apps Community Account Support | Power AutomateCommunity Account Support | Copilot Studio  Community Account Support | Power Pages

Super User of the Month | Chris Piasecki

In our 2nd installment of this new ongoing feature in the Community, we're thrilled to announce that Chris Piasecki is our Super User of the Month for March 2024. If you've been in the Community for a while, we're sure you've seen a comment or marked one of Chris' helpful tips as a solution--he's been a Super User for SEVEN consecutive seasons!       Since authoring his first reply in April 2020 to his most recent achievement organizing the Canadian Power Platform Summit this month, Chris has helped countless Community members with his insights and expertise. In addition to being a Super User, Chris is also a User Group leader, Microsoft MVP, and a featured speaker at the Microsoft Power Platform Conference. His contributions to the new SUIT program, along with his joyous personality and willingness to jump in and help so many members has made Chris a fixture in the Power Platform Community.   When Chris isn't authoring solutions or organizing events, he's actively leading Piasecki Consulting, specializing in solution architecture, integration, DevOps, and more--helping clients discover how to strategize and implement Microsoft's technology platforms. We are grateful for Chris' insightful help in the Community and look forward to even more amazing milestones as he continues to assist so many with his great tips, solutions--always with a smile and a great sense of humor.You can find Chris in the Community and on LinkedIn. Thanks for being such a SUPER user, Chris! 💪🌠

Find Out What Makes Super Users So Super

We know many of you visit the Power Platform Communities to ask questions and receive answers. But do you know that many of our best answers and solutions come from Community members who are super active, helping anyone who needs a little help getting unstuck with Business Applications products? We call these dedicated Community members Super Users because they are the real heroes in the Community, willing to jump in whenever they can to help! Maybe you've encountered them yourself and they've solved some of your biggest questions. Have you ever wondered, "Why?"We interviewed several of our Super Users to understand what drives them to help in the Community--and discover the difference it has made in their lives as well! Take a look in our gallery today: What Motivates a Super User? - Power Platform Community (microsoft.com)

March User Group Update: New Groups and Upcoming Events!

  Welcome to this month’s celebration of our Community User Groups and exciting User Group events. We’re thrilled to introduce some brand-new user groups that have recently joined our vibrant community. Plus, we’ve got a lineup of engaging events you won’t want to miss. Let’s jump right in: New User Groups   Sacramento Power Platform GroupANZ Power Platform COE User GroupPower Platform MongoliaPower Platform User Group OmanPower Platform User Group Delta StateMid Michigan Power Platform Upcoming Events  DUG4MFG - Quarterly Meetup - Microsoft Demand PlanningDate: 19 Mar 2024 | 10:30 AM to 12:30 PM Central America Standard TimeDescription: Dive into the world of manufacturing with a focus on Demand Planning. Learn from industry experts and share your insights. Dynamics User Group HoustonDate: 07 Mar 2024 | 11:00 AM to 01:00 PM Central America Standard TimeDescription: Houston, get ready for an immersive session on Dynamics 365 and the Power Platform. Connect with fellow professionals and expand your knowledge. Reading Dynamics 365 & Power Platform User Group (Q1)Date: 05 Mar 2024 | 06:00 PM to 09:00 PM GMT Standard TimeDescription: Join our virtual meetup for insightful discussions, demos, and community updates. Let’s kick off Q1 with a bang! Leaders, Create Your Events!    Leaders of existing User Groups, don’t forget to create your events within the Community platform. By doing so, you’ll enable us to share them in future posts and newsletters. Let’s spread the word and make these gatherings even more impactful! Stay tuned for more updates, inspiring stories, and collaborative opportunities from and for our Community User Groups.   P.S. Have an event or success story to share? Reach out to us – we’d love to feature you!

Top Solution Authors
Top Kudoed Authors
Users online (3,795)