Redeveloping Your Established Data Model Using a Managed App

Hello, and welcome to another X Force Data Summit presentation. Today, we're happy to have Mark Jones, who's a data coordinator at a nonprofit called Oasis Community Housing. And Mark is gonna tell us about how we worked with them to work through their data model and get their data model redeveloped. And I'm sure he'll do a better job of explaining what he's gonna say than I just did. But thank you Mark for joining us.

Take it away.

Great. Well, thanks Leonard for having me and thank you for that introduction.

As Leonard said, I'm Mark, I work for Oasis Community Housing, which is based in the Northeast of England predominantly.

And I have been at Data Quarter since twenty seventeen.

To begin with, I'm going to tell you a little bit about myself just so you get a little bit of the background.

And I always think it's helpful for people attending a talk or a seminar to know who's presenting.

So I'm going to just cover a little bit about who I am and then a little bit about Oasis before we dive in.

So about me.

I like a lot of people became a Salesforce admin almost by accident in twenty sixteen.

I started working for a charity which was an Oasis community housing. And on the job interview, the chief executive of the company asked me, have I ever seen Salesforce before?

And I had seen Salesforce. My dad who was with us at the time worked for Honeywell, a massive international organisation who have a huge Salesforce org. So I've seen bits and pieces of Salesforce and how that works from my dad.

So I just said, yeah, I've seen Salesforce, know a little bit about it. And when they offered me the job, I came on my first day of work and said, you mentioned you'd seen Salesforce before, you're developing our Salesforce org for us.

So it's a little bit of a baptism by fire.

No real experience with Salesforce other than seeing it. So there was a lot of learning on that job. And about a year later, I moved over to always a community housing as their data coordinator, where I was in charge of their Salesforce org, which use a managed package called inform. And you'll hear a bit about that during the presentation.

And at the moment we are still redeveloping the org and have been since really the summer of last year. August twenty nineteen is when we began.

And so there's a lot of work gone into it. And at this stage, the project I would say is about sixty to seventy percent done.

We're kind of now doing some of the bits of work that need to be done once you've done a job like this, but we'll get into that in a little bit.

In twenty nineteen I spoke at my first Salesforce event and it was an event called Inspire East in Cambridge in the UK. And this was my first time speaking outside of Christian context, as a Christian charity and I myself attend church in the UK and all my speaking opportunities from before that was in a church setting. So this was a very different experience.

Since then I've become a community group leader with the Trailblazer Community Programme, leading a group in the North East of England and have been working on building up a network of user groups in the North East. We have quite a big pool of Salesforce talent in that area covering admins, developers, architects, CTOs and the like.

So I became a community group leader last year and we started the user group at the beginning of this year.

I became a Trailhead mentor as well in January of this year and I'm now mentoring three different individuals.

And overall, I've built five different Salesforce orgs since twenty sixteen.

Each with a variety of different reasons for them and for a variety of different groups, a couple of them for charities.

And that's kind of been a big learning curve as well, looking at developing different areas of bespoke work for them.

I'm also now providing support as part of my work to over one hundred different people who use the inform package specifically. That covers staff within Oasis Community Housing and two of our organisations as well in the North East of England.

And there's more potentially in the pipeline this year.

So that's a little bit about me.

A little bit about Oasis Community Housing, just so you know again about who we are and this presentation is based on my work with them.

So OAS Security Housing is a national homelessness charity in England, predominantly based in the North East as I've mentioned.

And we have projects spanning the North East and we also have two projects in London as well, where we work with at risk vulnerable people from young to old.

And we have different projects.

We have some residential projects where young women would come and live with us and we will support them to help them try and find work and ultimately find their own accommodation which they can look after and live on their own and manage themselves outside of that. And we also have some crisis services as well for people who are struggling for rough sleeping, sleeping on the streets, being out of work. So we have quite a lot of different work that needs to be done and that's relevant to this kind of subject because there's a lot of different needs within the organisation.

So that's a bit about Oasis community housing and kind of give you a little bit of background on our history with Salesforce because it's kind of important to me to fill that in as well.

So we know a bit about why this work had to be done. I'm going to talk to you about in just a bit.

In twenty fifteen, Oasis Community Housing purchased the Informed managed application from Homeless Link who developed it and that's managed up on Salesforce.

And basically over a number of months that was developed between Oasis Community Housing and Homeless Link, it was rolled out to some staff as part of a pilot project in August, twenty fifteen with a full roll out happening in January twenty sixteen. As mentioned, I then joined the organisation in twenty seventeen in June specifically, and I was the first member of staff to actually be solely responsible for Inform for community housing.

Prior to that we relied on staff who were part time and had to do inform on top of their over duties.

So as you can imagine, there wasn't that much of a priority to some of the staff. So they had their jobs to do as well as managing the Salesforce org using InForm.

When it was available to staff generally, we start off with about forty users. Now we're over sixty.

The last count it was sixty three users that we have. And that's fluctuates as well quite regularly for us. So since I've been in post, we've had over a hundred different people using our specific Salesforce org who have come and gone.

But we're sitting at sixty three at the moment.

So to really get into the nuts and bolts of why this project was needed.

Of all things, to start off with a meeting to discuss KPIs for the organisation, so our targets. And the germ of this project really started when our chief executive asked us to look at how we could record information on the children living with service users in our residential projects.

And at the time all we were really capturing on those children was that they were living in the projects.

So my first response to that was we don't capture anything.

So that kind of began a big process of really reviewing what we were capturing, why we were capturing it. Because with coming in to the organisation two years after we adopted Salesforce, I came into something that was already developed and that's in some ways, in a lot of ways actually good cause it means there's less work in terms of the development initially. However, in my case, it's actually being more work because we've got to a point where I've seen requirements that we wanted that weren't on the system.

For the first year was mainly kind of looking after what was already built, helping staff to work with what was already there.

And then came the need to readdress what we were capturing and why we needed it. So that's how this whole process started.

And after a lot of work, it came to the conclusion that we needed a different approach.

And the plan was to really streamline the data that we were capturing.

I'll talk about the research that we did in a bit.

But one of the things that we had from staff feedback in researching was that the system was quite clunky and it took a lot of time for staff to input data.

And as an admin, one the things that you might well understand and imagine a lot of people here do is that when you try and make something simple for staff, it makes things a lot more complicated for the admin. It's always a lot more work, but the idea was to make it so that staff could record high quality data that we need and that actually benefits us because as a charity, we are dependent on the funding that we receive from outside of the organisation.

So wanted to record something that actually covers the base of what we do on a day to day basis, but also we can use to sell ourselves to external funders and on social media and all the like.

So it was a bit of a mixed bag of requirements.

So I say we reviewed the whole of the pack inform app that we were using.

We received feedback from the staff across the organisation. We asked every member of staff to contribute to that and not everybody did contribute, but we got the majority of staff did. The majority of them were staff who used the Salesforce org for us who used the Inform app.

But a lot of them actually staff who were stakeholders in the organisation who don't use it on a daily basis, but had opinions on what they would want to see coming out of the system for their work. So some of the feedback that we got was good.

Some of it wasn't so good as you can imagine.

One the things I found somewhat upset at the time was that only thirty eight percent of our staff felt that Inform in its current form was very useful.

And thirty three photo was useful to some degree. And twenty five percent of staff had no opinion on whether it was helpful to them or not.

We asked staff to rate the system on a scale of one to ten as well. So just to have a helpful numeric feature and thirty three percent of staff, which is the biggest figure that we had for that rated it as a seven.

So overall, more staff are kind of written the quality of the system towards the middle ground really.

Would have much preferred a higher figure on those things, but that's a good learning curve.

And that's one of things I would suggest when looking at doing a job like this is check reviewing with the staff first and seeing what their feedback is because they can, their views can be very helpful to point you in the right direction. So a few things I learned from that research phase was that the users of the org needed to be able capture the data in a bespoke way.

One of the big bits of feedback we had was that some of the areas that they had access to weren't relevant for their work.

Couple of things I learned was that we needed to lower the amount of objects required. Some staff had access to upwards of twenty different objects at a time, which for when you've got a range of IT competency across the organisation, sometimes I found that many different objects the staff would potentially have to use is a big ask.

So I wanted to lower that or just say to kind of condense that down. So that wasn't such a big labourous task for them to input the data.

And one of the bits I learned from that was that how we were linking various people together need to be much more simple.

The way inform was built originally was that they used the accounts object to record the organisations projects and you would have the service users as contacts.

But if you had service users, if we want to capture children of service users, we wouldn't be linking them at that time through the account object, which from a Salesforce standard perspective is quite a bit of a challenge.

One of the better ways to do that kind of thing would be through the account and contact model. Even if you read label accounts to something different, we're using that basic setup as actually the best way of keeping people together.

Like say, creating like a household account, for example, which is standard within MPSP for anybody who has seen that in the nonprofit circle.

So the plan in Symblu in a nutshell was to create a multi app org using Lightning apps. So we moved from Salesforce Classic to Lightning the year before this review was done.

So we wanted to use the Lightning apps to build a multi app org where each bespoke area of work had their own app.

And they would share some areas in common.

So they would share the context object, the accounts object, and they would share other objects, but each app would have bespoke views.

They would have different report charts that would appear on their pages. And so essentially it was a customised approach for each department essentially for us.

The improved app approach would lean heavily on tools like Flow and Process Builder to help create better automation. One the things that we had, which as an example, which I always found a bit more of a bug bear was that we have an object or had an object at time called CCIE, which is an alert, a client alert.

And we would want staff to be sending them to approval to managers.

And when it was originally built by Homeless Inc staff would have to click the submit approval button. And in my experience, about seven times out of ten staff would forget to click the button.

So I wanted to use process builder to lean on that to automatically submit those alerts for approval. And that's one example.

Other examples would be email alerts and notifications.

Wanted to use the system to send staff emails if say a case was about the clause on the service user, for example. So say at the time of writing, the redevelopment is around sixty to seventy percent done with the main bulk of work now being important historical data into the new areas.

That's been one of the challenges and I'll talk about that in some detail in a bit when I talk about what I've learned through the process.

But to do what I've been doing, I've had to take out historic data from old objects and then move them into new objects due to the chance of having a managed app.

And the chance of having a managed app can be that some fields will be only able to be edited apart from people who actually have management access to that app itself. So for us, those fields in some of the objects where we didn't need them anymore and they couldn't be changed. So I had to come up with approaches to work around that.

So bloodless and mishaps, as I've called it.

One of the big things I noticed straight away was we had the challenge of having to do this live.

And in all honesty that if you were to do this kind of project yourself, I would recommend Sandbox rather than doing it live.

You can do it live and you can do it well by doing it live. But if you are able to push to get it done in the sandbox, it's much better doing a sandbox. It takes away some of the headaches.

And what you can do is you can do the whole project in a sandbox and roll it out once you're done. That's a much easier approach if you can do it in that way.

We didn't have that luxury from the requirements of management. So we worked around it.

And one of the more challenging ones I had was the first rule of trying to move the data across.

We had data that went to the wrong person, for example. So we had client records that went to the wrong client.

Thankfully I had backed everything up and that's one big recommendation I would always say, back your data up. So the way we approached it was that we kept all the old records in their place, in the objects that were in, and they were staying there until the migration was complete. So although it was a bit of a headache, it wasn't the end of the world. But for us, that was one of the chances that we had.

And we found when I looked into why that was the case, we found quite a bit of historical errors in data that was inputted, which is something that is very not something that I can necessarily prevent. So I thought that was a bit That's one of the more humorous ones.

But thankfully the data was backed up and that saved our skin in that area. So the other ones that we had was changing the way certain pages looked from one day to another and staff come at us and go on, why is that all of a sudden changed?

That wasn't there yesterday. Why does this look different now?

And we've had quite a few occasions where staff have said, I can't find this record.

And ironically, for this sitting pretty much right underneath their nose when you looked at what they were seeing on the screen.

So those are the kinds of things you might run into and there's ways to do that.

In terms of importing your data, I would recommend using the data report wizard.

If you can, don't use the data loader too much. That was how we had the issue with the data going to the wrong person.

We used the theatre loader application, which is a great tool as it does a lot of records at the same time.

However, it doesn't necessarily filter out any data that's got inaccuracies at times.

So that was one of the challenges that we had.

So we're using the data import wizard instead. Things I've learned so far with the project.

And I think this kind of stuff is really helpful and really important for us to understand in this kind of work is that sometimes it's okay to hit the reset button.

I did that twice during the process.

Before we moved to the multi app model, I had planned just to make it similar to what we had originally, but to do improvements. So basically it would be one app for the entire organisation where we would have different objects for different areas of the company.

And we tried that approach and some of the feedback we got from staff was it's still too clunky.

It's still a bit too much work for us to input the data.

And that kind of brought in the idea goes, actually we need something bespoke for each area really to kind of ease up on those challenges.

Over things I've learned help in the community is only a question of where.

Over the months of doing this I've learned very heavily on people that I know within the Salesforce ecosystem, either through success community or through people I know through my work as a community group leader.

So I regularly end up having email conversations or message conversations of LinkedIn with other community group leaders and picking their brains.

So it helps never too far away in this kind of thing.

CRM development isn't a case of one shoe fits all. That's a big learning curve.

If you're in a small organisation, yeah, it might be one shoe fits all approach for that.

But if you're in a bigger organisation with different requirements across the organisation and approach like this may be what you need.

Historical problems are pain to deal with. That's another one.

As I mentioned, when I did the first attempt at the migration of data found there was a lot of historical inaccuracies that no amount of reporting would tell you because you just work with that big a volume of data. So that's a bit of a pain at times.

Other things I've learned as well, somewhere, somehow, somebody will complain.

When you're making change of any kind, you will get resistance.

However, if you are passionate about what you do, you can really help staff to and users to actually embrace that change and work through them with that.

That does take some time with takes more time with some than others.

But I've found generally speaking, if you spend the time with staff, spend the time with users, they will start to embrace that change.

So the complaints, whilst they might be a bit hard at first, then they don't take too long necessary to get past.

Others have valuable insights to make a job like this work.

One of source I used regularly was a website called Salesforce Ben, which many admins here may have seen. It is a really good tool. And I've used a lot of stuff that's been written on there from like years ago even to help in this process.

As you've gone through it, you use the rule need lots of training during the process.

And that may have to be one on ones, could be group trainings, but you will have to give out regular training in that.

One of the bits of things I've learned is to give the project time.

Initially we had set this project to be about a year of work and a couple of months into it, I spoke with my manager and said, let's take off the deadline essentially.

Let's put deadlines on some of the more immediate tasks which are in it.

But for the project overall, let's just say this is a permanent thing because there's always improvements to make as you're going through a job like this.

And then the last one is on the things I've learned is breathe.

Sometimes I spent several hours working on this stuff and spent several hours outside of my paid employment At the back end of last year, I had amassed over one hundred hours of loo time, which I have never not taken. And so there is a lot of effort that goes into it.

And some nights you'll be, may almost be pulling your hair out because of some of the challenges that you've run into. But it's going to be fine.

You know, as we say, if you get stuck on things, there's plenty of people who can help. The success community is great as is the trailblazer community. And the sites I guess is like Salesforce Ben is really good. Salesforce Kidd is fantastic as well for stuff.

So there's always somebody else who will have went through the same challenge that you're going through with Salesforce and you will find answers. So brief, essentially it's the headaches aren't too big of an issue.

Was here. The results of the project itself is worth it if this is the kind of thing you want and need to do.

So the big real piece to kind of go through is how can you do a project like this yourself?

Because I've talked about my experiences, but what if you're thinking this is the kind of thing you might want to do or might need to do in your organisation?

So I've got some tips. I've got some things to make a note of before you start with a project like this. And I've got some tips as well for managing a project like this.

So things to note before you start is first one, it's simple question and it's one is one that when I raise this inspirers got some laughs in the room because the first question is, does it need to be done in the first place?

If it's a case of you're wanting to do this because you don't like the way it looks, that might not be enough of a reason to do it.

A job like this should really be done to leverage Salesforce to get the best result of your data for your organisation.

So if that's the pass out statistics to funders, social media, to your exec, to your management, Those are the kind of reasons this project should be done for to kind of get the most out of your system, to help your users, to work with the system easier and also to really use your data to sell yourselves really well and to store it in a good and high quality.

How much time will the project take? Like I said, in our case, we initially anticipated a year, but we ended up seeing let's not have a tight of a strict deadline on the finalising of this.

Let's put deadlines on the milestones, I guess you could see.

Recent example of this was we've just moved our housing department, which was the last department to move in this work that we've been doing to the new way of using Salesforce. And we just moved them over last week after many discussions with margin since really November trying to get them on to the new system.

We moved them over last week.

So have a think about what kind of timeframe you need to do this.

That may come from management.

But one of the things I would say is if your management set a timeframe and if you think it's not going to be feasible, talk to them. I've found in my experience that management can be quite flexible if you give them good reasons as to why you need a bit longer on certain jobs or if you can do jobs quicker as well.

They really do like if you do jobs quicker than their original deadline as well.

Other things, what additional resources or training might you need as well. Again, you can lean very heavily on different resources out there.

At my office I now have a bookshelf full of Salesforce books, which proved very helpful as well. So have a look at kind of what resources or an additional training you might need.

Other thing again, like I mentioned, will this work be done live or in a sandbox?

If anything I've said so far is sticking out, hopefully it might be that to try and to do this first in the sandbox because really doing it that approach will be far easier on you as an admin. Obviously if you have to do it live, you can do it live.

What new features are going to be added? So thinking things like validation rules, flows, processes, email alerts, and even third party apps.

One of the things that we integrated fairly recently in terms of the development was the sales force, third party component called CMTD enhanced related lists. Well, we started to use that dynamically to show records from the current day. So we have an object that we have for a service user called case where all of the work that we do with them is logged in that.

And we have a list that pops up using that CMTD enhanced related list product for case rate that's happened on the current day. So staff can hop into a service user's record and they can see if any work's been done with that service user on that day.

That's an example for us. There's other ones that we have implemented.

So that's the kind of things you want to be thinking about with your new features.

What validation rules, processes, third party apps you might want to do and want to include.

If live, what work needs to be done to ensure the smooth migration of data.

That's a big one.

Like mentioned before, we had that challenge where the first attempt to migrate the data, we had records going to the wrong service user.

And for us, thankfully I said that wasn't too much of an issue because we kept the data the historic data stored as well. So what we will do is we have to remove all the new data that we'd imported and go back to the old data and then start working through that a bit more gradually.

So you want to have a look at how you would migrate the data.

We've been doing it more recently in phases. So rather than trying to import everything in one go, we've went through different stages and working through any anomalies that happen because you will sometimes run into anomalies that happened when you import data. So we've been working through that as well.

How is the project going to be managed?

Is it going to be complete up to you?

Is it going be run with a team of people?

In my side of things, it's pretty much me who's looking after it and just feeding into management and relevant staff. What changes are coming for you and your organisation? You might have to have a team of people working on it with you.

In my side, it's been a bit more of a case where it's just been me who's been doing all of that work.

So some tips for managing a project like this.

Plan out the project and Think through kind of the time frame that you need to do that. Think through the practicalities.

If you're going to do it fears by fears, think of things like what, who's going to go onto the new way of doing things first and plan those things out.

Determine the required integrations. So with that, I as I'm thinking things like third party applications, additional tools that aren't already native to your instance of Salesforce.

With that, you're going to have to look into things like how, if there's any ones that need to be paid and then to go obviously through how you approve those payments as the organisation. There's a lot of good free ones out there as well.

Another example of one that we use one called, it's a record map one. I forget what the exact name is, but it's a free one that's on the app exchange. And what you do is you determine what fields from a particular object you're using for the address and it'll bring up a Google map of that location. So we use that for properties that we have in our portfolio.

Determined required validation rules as well.

Validation rules are very helpful and they are very good to use as often as you can. I would say one example is that we have of a validation rule that's in place is on our casework object where we have some staff who don't use, who we need to record who's done what work but don't have a Salesforce licence.

So we have their names in a pick list.

But we also have staff who would use the same record who have a Salesforce account. So what we have is you have two fields for asking who's logged that particular work. And the validation rule we have in place for that is if the local field for the user is blank, the pick list is required.

And that validation rule inverts on a self safety pick list is set to none, they'll ask you to fill in the lookup field.

So that's an example of ones that we use.

And we have quite a few more that we use as well.

As well determine the required processes in process builder. You might currently be using Workflow Rule. We use Process Builder.

Workflow Rules do similar work. Although I would personally recommend Process Builder, especially in Lightning. It's more, it's quite a bit more powerful and you can link it to very easily to flows or to approval processes. So I mentioned before the example of our client alerts that we ask staff to submit for approval.

Now what we have is we have a process in place where if a particular type of alert we call an incident is recorded, once that's saved, it'll go to approval to the manager and the users don't actually have to do to submit it. It'll submit automatically.

And that's an example of a process that we use.

And we've got a bit of a library going essentially with processes and process builder is a really helpful tool.

Again, take your time with it.

If you've got a deadline, obviously try and work within your deadline.

But I would say don't rush it. That's kind of what I mean by take your time with it.

When you rush a job like this, you will encounter have mistakes and mistakes are okay, but you want to learn from those mistakes. Regularly back up your data as well.

That's a real helpful one, especially if you're moving lots of data around. So we at Always Community Housing, I have set up a weekly backup. So I get an email once a week from Salesforce where everything that records backed up.

So I do that once a week.

I was doing that beforehand anywhere but that's something that I started doing over a year. Well, two years ago now actually. And before this project even began, but regularly backing up your data and you can have Salesforce send you that update on a weekly basis, which is very helpful as well.

Again, I've mentioned before, sandbox if possible. It is a real helpful tool for that.

Keep users regularly update.

When you're doing a big job like this, especially if you're having to do it live like what we've had to do, it's good to keep your users informed to give them a bit of peace of mind and to also give them opportunities to come back to you and ask questions if they have them around that.

Most admins that I find who are like the only admins such as myself they generally tend to do very basic development work as well. Some working with complex floors and the like.

And the thing I would say with that is test that workout regularly.

If you're building things like floors and you can use the debug area in floor to help with that.

But test that work regularly because what you don't really want to have happen is for you to roll it out and for it to not work.

So tests you work out regularly when you produce some things like that. That also applies to process builder as well.

And validation rules test these things out as much as you can.

Use tools like Trailhead and the Success Community. Again, I've mentioned like the community around Salesforce help is really great and it's very helpful for jobs like this.

And Trillhat has a lot of really good stuff on there.

Before I started working on the floor side of things for this project, I hadn't done any floors before. I had done lots of things with process builder and workflow rules, but never anything with floors.

And so I did a drill head on floors.

And since then I've built a good thirty different floors in New York. Some of them are still being worked on due to the demands of the project.

But Trill Head is a fantastic resource for you in those areas.

Don't beat yourself up with things don't work at first.

Like I said, we had to hit the reset button on the project twice in initial stages because of things that we ran into because I had an idea of how the project would look and as going into it and come to a conclusion, it needs to be done a little bit differently.

And you might find again, things don't work. Like again, I mentioned about the data issue that we had in the first instance.

When I first realised that was the case, I really kind of felt a bit bad about that because like, Oh, this is so much data.

But again, like I say, we'd had it set up so that it wasn't really an issue. We could just remove all of that data we'd imported because we still had the historic data stored and not for the most part was fine.

So if you run the things that don't quite work the way you want, don't beat yourself up by it. What I would suggest is looking into why those things haven't worked and then work on it from there. And you can always tweak the things that have been a bit challenging and also give yourself some room to think and to breathe on it.

One of things I've learned in this project is that, of course, great to have input from users. Sometimes that input will be almost overwhelming. You'll have people come up with all these different ideas, some of them great, some of them you probably don't want to touch at all because they would not be helpful.

So sometimes you need to give yourself a little bit of space to kind of deal with that noise and to kind of work through all of the things that are going on with that job and to kind of pick out what's worthwhile, what isn't, and also learn to shut out the noise a little bit.

So those are the tips I would say on that.

And that kind of really brings me to the end of the talk.

Hopefully you found our experience somewhat helpful.

My email is here on the screen and I'm also, you can find me on places like LinkedIn and more than willing to talk to people if you have any questions on this kind of stuff. But that's kind of really what I've got to share. So hopefully that's been helpful and hope you've enjoyed the talk.

Thanks Mark. I had a couple of questions.

So you're saying that you migrated people from one thing to the other. Are you running out of two orgs? Like moving people from one org to the other one or how are you managing that?

Yeah, so what I mean by that maybe wasn't too clear on that, but we have, it's moving data around different custom objects essentially. So when the org was built originally due to some of the limitations of having a managed app, we couldn't change things on those custom orgs that were built.

So the biggest on for us for that was a custom object that was labelled timeline events where they had it linked to the accounts object, which they were using to point to project within the organisation.

Whereas I wanted us to move back to a more traditional model of a contact account style model.

And with a managed app, we weren't able to take fields out of page layouts in for that object.

So the work was to retire that custom object and to move them into essentially a new version of that object. So we created a new object which we label as cases because that's for us as an industry standard term.

So it was moving data from an old custom object that was going to be retired to a new one.

Okay. So basically you enable those custom objects when you array for the users to look at them.

That makes sense. So are you basically ditching inform then?

So we're trying to keep us true to the inform package as we can because we didn't want to completely throw away what had been done.

We wanted to do with it was improve our usage of inform and keep us true to the product as we could, but also making it bespoke for us as well.

So most of the model that they have, we've just tried to streamline what they were already using and to keep true to say to what they had originally built.

So many a lot of it's been recreating new versions of their objects so that we could use them but keep them true to them because staff are familiar with info.

That makes sense.

And so basically you're saying that seventy percent of your staff has been converted over to the changes that you made seventy plus percent. And then you're still working on the remaining thirty percent.

So when I say the project is about seventy percent Don, that's not necessarily about the staff using it. All of our staff are now using the new versions of it.

But with those having to do it live, there's certain things that are having to be worked on still while staff are using inform that we've been building.

So I mentioned like the account contact model that we've been working with that hasn't been fully fleshed out yet.

And that is one of the areas that's in that remaining thirty percent of work.

So we've just moved our last department over to the way we're building it.

And we should hopefully be able to get within the next few weeks, even the next month, The account contact style of doing it built like we want to.

So we just have to clear off that data. So the remaining thirty percent of work is around busy tweaks to the system, like the account contact model.

Other ones to do with how we do our assessments of service users, those kinds of things. But all of our staff are using the new way of working on the org.

Good. Good. Well, Mark, thank you so much for sharing your experience, especially your experience going from zero to help to mentor as administrator and also, you know, streamlining your org as fixing the airplane while it's flying basically. Yes.

Well, thank you very much and hope it's been good.

Yeah, and thanks for spending your evening with us.

Oh, well, thank you very much.

‍